[C++] Image resize met alpha

[Olaf van der Spek]

Weet iemand waar ik een functie kan vinden die plaatjes (al ingelezen, dus geen bestanden) met alpha component (1-bit) kan resizen?

[.oisyn]

?

kun je dat zelf niet gewoon?


.edit:

code:

class Image
{
public:
    int width, height;
    unsigned short *  buffer;

    Image ()
    {
      width = height = 0;
      buffer = NULL;
    }

    unsigned short getPixel (float x, float y)
    {
      return buffer[(int)y * width + (int)x];
    }

    void resize (int toWidth, int toHeight, Image * fromImage)
    {
      if (buffer)
        delete[] buffer;

      width = toWidth;
      height = toHeight;
      buffer = new unsigned short[width * height];

      float dx = (float)fromImage->width / (float)width;
      float dy = (float)fromImage->height / (float)height;

      float y = 0.f;
      int offset = 0;

      for (int iy = 0; iy < toHeight; iy++)
      {
        float x = 0.f;
        for (int ix = 0; ix < toWidth; ix++, offset++)
        {
            buffer[offset] = fromImage->getPixel (x, y);
            x += dx;
        }
        y += dy;
      }
    }
};

nou geeft dit nogal een blokkerig effect, maar je zou getPixel () aan kunnen passen zodat ie tussenliggende pixels uitrekent

.edit2:

code:

unsigned short getPixel (float x, float y)
{
    float ux = floor (x), uy = floor (y);
    float lx = ceil (x), ly = ceil (y);
    float f, r, g, b, a;
    unsigned short c;

    c = buffer[(int)uy * width + (int)ux];
    f = (x - ux) * (y - uy);
    r = (float)(c & 0x001f) * f;
    g = (float)(c & 0x03e0) * f;
    b = (float)(c & 0x7c00) * f;
    a = (float)(c & 0x8000) * f;

    c = buffer[(int)uy * width + (int)lx];
    f = (lx - x) * (y - uy);
    r += (float)(c & 0x001f) * f;
    g += (float)(c & 0x03e0) * f;
    b += (float)(c & 0x7c00) * f;
    a += (float)(c & 0x8000) * f;

    c = buffer[(int)ly * width + (int)ux];
    f = (x - ux) * (ly - y);
    r += (float)(c & 0x001f) * f;
    g += (float)(c & 0x03e0) * f;
    b += (float)(c & 0x7c00) * f;
    a += (float)(c & 0x8000) * f;

    c = buffer[(int)ly * width + (int)lx];
    f = (lx - x) * (ly - y);
    r += (float)(c & 0x001f) * f;
    g += (float)(c & 0x03e0) * f;
    b += (float)(c & 0x7c00) * f;
    a += (float)(c & 0x8000) * f;

    return (unsigned short)((int)r & 0x001f) | ((int)g & 0x03e0) |
         ((int)b & 0x7c00) & ((int)a & 0x8000);
}

dit natuurlijk ervan uitgaande dat je het RGBA:5551 formaat gebruikt
En de code is niet efficient (werken met fixed point getallen komt beter uit)

[Lurge]

dan zou ie het niet vragen.

[Janoz]

Het schalen van het alpha kanaal gaat net zo als het schalen van de andere kanalen. Het probleem dat je mischien tegenkomt is dat het alpha kanaal maar 1 bit is, maar dat IMHO niet zo'n heel groot probleem (<50% doorzichtig, dan opaque, anders doorzichtig)

[Olaf van der Spek]

Op dinsdag 15 januari 2002 16:43 schreef OiSyN het volgende:
?

kun je dat zelf niet gewoon?

Tuurlijk wel, maar dan moet ik nadenken. Zo makkelijk is het niet om een goede resizer met interpolatie te schrijven met alpha ondersteuning.

De resizer zonder alpha heb ik al, maar dan krijg je zo'n raar paars effect op de overgangen (net als soms op TV).

[.oisyn]

Op dinsdag 15 januari 2002 17:01 schreef OlafvdSpek het volgende:

Zo makkelijk is het niet om een goede resizer met interpolatie te schrijven met alpha ondersteuning.

denk het wel

De resizer zonder alpha heb ik al, maar dan krijg je zo'n raar paars effect op de overgangen (net als soms op TV).

Dan doe je toch iets niet goed...

zie mijn edit in mijn 1e post

[Olaf van der Spek]

Ik had je edit niet gezien. Het gaat om manier 2. Source image is 8-bit, dit wordt geexpand naar 32-bit, geresized en weer naar 8-bit geconverteerd. Ik denk toch dat jouw getPixel fout is.
Stel bijvoorbeeld dat je 4 pixels hebt, een zwart (linksboven) en de rest wit. De zwarte is 100% opaque, de witte 0%. Je wilt de pixel in het midden interpoleren. Dan komt jouw code uit met grijs (75%) en alpha (25%).
Die alpha klopt wel, maar die kleur zou dan toch zwart moeten zijn.

Deze code werkt (volgens mij) trouwens alleen goed voor resize up. Voor resize down krijg je rare resultaten.

[.oisyn]

Op dinsdag 15 januari 2002 17:32 schreef OlafvdSpek het volgende:
Stel bijvoorbeeld dat je 4 pixels hebt, een zwart (linksboven) en de rest wit. De zwarte is 100% opaque, de witte 0%. Je wilt de pixel in het midden interpoleren. Dan komt jouw code uit met grijs (75%) en alpha (25%).
Die alpha klopt wel, maar die kleur zou dan toch zwart moeten zijn.

nee, 75% grijs, zoals je zei. Hoe kan dat nou zwart zijn, als 3/4e van de pixel wit is

Deze code werkt (volgens mij) trouwens alleen goed voor resize up. Voor resize down krijg je rare resultaten.

nou ja, rare resultaten, je krijgt last van aliasing (daarom worden er mipmaps gebruikt bij het tekenen van polygonen), maar dat treedt pas op als je meer dan 2x verkleint (dus bij minder dan 50% van het origineel)

[curry684]

Ben je met de Win32 AlphaBlend functie niet gewoon klaar?

Doet scalen, ieder mogelijk formaat, source en dest mogen alpha channels hebben, en eventueel een globale alpha constante erbij.

Heb je alleen geen ondersteuning voor Win95/NT, maar da's wel te overleven denk ik zo?

[Verwijderd]

Op dinsdag 15 januari 2002 19:10 schreef curry684 het volgende:
Ben je met de Win32 AlphaBlend functie niet gewoon klaar?

Doet scalen, ieder mogelijk formaat, source en dest mogen alpha channels hebben, en eventueel een globale alpha constante erbij.

Heb je alleen geen ondersteuning voor Win95/NT, maar da's wel te overleven denk ik zo?

Gefeliciteerd! Een eenvoudig, klein probleem omgetoverd in een niet-portable applicatie!

[.oisyn]

Op dinsdag 15 januari 2002 21:13 schreef Bananeman--- het volgende:

[..]

Gefeliciteerd! Een eenvoudig, klein probleem omgetoverd in een niet-portable applicatie!

wie ben jij en waarom maak je zo'n gare first post? Je kan ook wel gewoon normaal reageren hoor

[Verwijderd]

Op dinsdag 15 januari 2002 21:16 schreef OiSyN het volgende:

[..]

wie ben jij en waarom maak je zo'n gare first post? Je kan ook wel gewoon normaal reageren hoor

Oh niks, ik geniet er gewoon van om me op mijn 2e dag op GoT meteen thuis te voelen!!

[curry684]

Op dinsdag 15 januari 2002 21:16 schreef OiSyN het volgende:
wie ben jij en waarom maak je zo'n gare first post? Je kan ook wel gewoon normaal reageren hoor

Afgezien van de OS/2 fascinatie heb ik wel een vermoeden... betreffende persoon is volgens MSN Messenger online, gaat graag onder het pseudoniem Bananeman en heeft een neiging op zo'n manier te reageren. Zal wel onzin zijn, en anders: Hoi Ruud

En om op het non-portable terug te komen: klik eens op OlafvdSpek's naam om een search te doen op alle topics waarin ie gepost heeft, en kijk eens hoe vaak daar VC++ en Windows XP opduiken. Mensen die hier langer dan een dag rondhangen weten bij de meeste veul-posters wel binnen welk gebied ze opereren, vandaar mijn Win32 antwoord.

Portable graphics-applicaties schrijven in C++ is sowieso bullshit, pak dan Java en develop 10 keer zo snel en 10 keer zo portable.

[Verwijderd]

Op dinsdag 15 januari 2002 21:44 schreef curry684 het volgende:

[..]

Afgezien van de OS/2 fascinatie heb ik wel een vermoeden... betreffende persoon is volgens MSN Messenger online, gaat graag onder het pseudoniem Bananeman en heeft een neiging op zo'n manier te reageren. Zal wel onzin zijn, en anders: Hoi Ruud

Hallo, "Niels". Dat zag ik net in je profile. Verder heb ik geen flauw idee wie Ruud is. Bij het registreren was er wel nog een andere Bananeman, vandaar de --- achter m'n naam. Misschien bedoel je hem. Stuur 'm eens een mailtje, misschien vindt hij ook wel dat studie voor mietjes is! (zie wederom profile). Wat voor studie heb jij gedaan, Niels? Ik technische natuurkunde, zeker niet voor mietjes.

En om op het non-portable terug te komen: klik eens op OlafvdSpek's naam om een search te doen op alle topics waarin ie gepost heeft, en kijk eens hoe vaak daar VC++ en Windows XP opduiken. Mensen die hier langer dan een dag rondhangen weten bij de meeste veul-posters wel binnen welk gebied ze opereren, vandaar mijn Win32 antwoord.

Ik gebruik veel OS/2 en Windows98, maar schrijf software die ook onder Linux draait. Dat zegt dus helemaal niks. En misschien moet je Olafje wel helpen om betere, portable code te schrijven in plaats van hem fout bezig te laten zijn. Dat is uiteindelijk het doel van advies geven.

Portable graphics-applicaties schrijven in C++ is sowieso bullshit, pak dan Java en develop 10 keer zo snel en 10 keer zo portable.

kijk, dat vindt ik nou een interessante opmerking. Ik ben het er namelijk helemaal niet mee eens. Wat dacht je van Borland, met Kylix? Ik heb sinds Turbo Pascal niet meer met hun producten gewerkt, maar zij hebben een systeem gebouwd waarmee je onder Win32 en Linux applicaties kunt bouwen. (nu OS/2 nog............)

C++ is op zich gewoon 100% portable.

Welterusten, Niels!

[ Voor 3% gewijzigd door curry684 op 02-02-2004 21:26 ]

[curry684]

Op dinsdag 15 januari 2002 22:20 schreef Bananeman--- zijn derde, eveneens zeer gare post:
kijk, dat vindt ik nou een interessante opmerking. Ik ben het er namelijk helemaal niet mee eens. Wat dacht je van Borland, met Kylix? Ik heb sinds Turbo Pascal niet meer met hun producten gewerkt, maar zij hebben een systeem gebouwd waarmee je onder Win32 en Linux applicaties kunt bouwen. (nu OS/2 nog............)

BCB/Delphi en Kylix zijn absoluut niet 100% compatible, en volgens de paar reviews die ik over Kylix heb gelezen is het onmogelijk een applicatie erin te schrijven die langer dan 5 minuten stabiel draait omdat het framework botweg nog niet af is.

Ennuh ik denk dat er eerder een Commodore 64 versie komt van Delphi dan eentje voor OS/2, grotere gebruikersgroep...

C++ is op zich gewoon 100% portable.

Goh vandaar dat ik zelfs onder 2 Windows-compilers al eens 997 (!!!!!!) fouten uit een project heb moeten halen om 'm onder allebei compilerend te krijgen.

De C++ definitie is 100% portable, nu nog een 100% portable implementatie...

[MSalters]

Op dinsdag 15 januari 2002 22:31 schreef curry684 het volgende:

[..]
Goh vandaar dat ik zelfs onder 2 Windows-compilers al eens 997 (!!!!!!) fouten uit een project heb moeten halen om 'm onder allebei compilerend te krijgen.

De C++ definitie is 100% portable, nu nog een 100% portable implementatie...

Tsja, meestal moet ik al fouten uit 'n project halen om 't op 1 platform te compileren. Maar wat portable implementaties betreft: Comeau en Intel, allebei voor Windows, allebei 100% portable ?
Borland en Microsoft mogen wel bekend zijn, maar het zijn niet automatisch de meest portable.

[Olaf van der Spek]

Op dinsdag 15 januari 2002 18:53 schreef OiSyN het volgende:

nee, 75% grijs, zoals je zei. Hoe kan dat nou zwart zijn, als 3/4e van de pixel wit is

Die witte pixels zijn 0% opaque, dus die zie je niet in het origineel. Die mogen in het resultaat dus ook geen invloed hebben.

nou ja, rare resultaten, je krijgt last van aliasing (daarom worden er mipmaps gebruikt bij het tekenen van polygonen), maar dat treedt pas op als je meer dan 2x verkleint (dus bij minder dan 50% van het origineel)

Volgens mij krijg je al sneller rare effecten hoor. Stel dat je 2x verkleint, dan neem jij dus gewoon pixels 0, 2, 4, etc van het origineel.

[Olaf van der Spek]

Op dinsdag 15 januari 2002 19:10 schreef curry684 het volgende:
Ben je met de Win32 AlphaBlend functie niet gewoon klaar?

Doet scalen, ieder mogelijk formaat, source en dest mogen alpha channels hebben, en eventueel een globale alpha constante erbij.

Heb je alleen geen ondersteuning voor Win95/NT, maar da's wel te overleven denk ik zo?

Nee, eigenlijk niet. Ik test wel eens op NT. Verder gebruikt die functie geen interpolatie.

[Olaf van der Spek]

Op dinsdag 15 januari 2002 21:44 schreef curry684 het volgende:
En om op het non-portable terug te komen: klik eens op OlafvdSpek's naam om een search te doen op alle topics waarin ie gepost heeft, en kijk eens hoe vaak daar VC++ en Windows XP opduiken. Mensen die hier langer dan een dag rondhangen weten bij de meeste veul-posters wel binnen welk gebied ze opereren, vandaar mijn Win32 antwoord.

Dat XP valt erg mee/tegen. Ik heb het sinds een paar weken op twee machines thuis en alleen op de machine die ik bijna niet gebruik wordt XP vaak gebruikt, zelf gebruik ik gewoon nog Windows 98.

Portable graphics-applicaties schrijven in C++ is sowieso bullshit, pak dan Java en develop 10 keer zo snel en 10 keer zo portable.

Waarom zou het in C++ niet kunnen?

[.oisyn]

Op woensdag 16 januari 2002 10:03 schreef OlafvdSpek het volgende:

[..]

Die witte pixels zijn 0% opaque, dus die zie je niet in het origineel. Die mogen in het resultaat dus ook geen invloed hebben.

aha, op die manier... maar dan wil jij iets anders dan wat gebruikelijk is, want je kunt namelijk transparante pixels wel een kleur geven. Het doel is dan om bij uitvergroten de kleur over te laten lopen in de transparante kleur, en ook nog eens de transparantie laten overlopen van opaque naar transparant. Het is namelijk niet zo dat het alpha kanaal bepaald wat de factoren zijn van de pixels die je samplet

Je kan het natuurlijk oplossen door die 2e getPixel functie van mij aan te passen dat ie bij elke pixel checkt of ie transparant is, zo ja dan kun je de f, r, g, en b berekeningen overslaan. Ondertussen hou je een tellertje bij die het aantal opaque pixels bijhoudt, en op het laatst vermenigvuldig je elke r, g en b component met 4 / aantal_opaque_pixels (moet je natuurlijk wel effe checken of dat niet 0 is, want anders krijg je een deling door 0, en als ie 0 is is de kleur toch ongedefinieerd dus dan kun je net zo goed 0x8000 terug sturen)

[Olaf van der Spek]

Op woensdag 16 januari 2002 16:32 schreef OiSyN het volgende:

[..]

aha, op die manier... maar dan wil jij iets anders dan wat gebruikelijk is, want je kunt namelijk transparante pixels wel een kleur geven. Het doel is dan om bij uitvergroten de kleur over te laten lopen in de transparante kleur, en ook nog eens de transparantie laten overlopen van opaque naar transparant. Het is namelijk niet zo dat het alpha kanaal bepaald wat de factoren zijn van de pixels die je samplet

Ja, ik heb die transparante pixels toch ook een kleur gegeven, namelijk wit? Dat overlopen van transparantie ben ik met je eens. Maar dat overlopen van de kleur is alleen van toepassing als de andere pixels semi-opaque zijn, niet als ze transparant zijn. En zelfs dan heeft de alpha component invloed op de kleur.

Je kan het natuurlijk oplossen door die 2e getPixel functie van mij aan te passen dat ie bij elke pixel checkt of ie transparant is, zo ja dan kun je de f, r, g, en b berekeningen overslaan. Ondertussen hou je een tellertje bij die het aantal opaque pixels bijhoudt, en op het laatst vermenigvuldig je elke r, g en b component met 4 / aantal_opaque_pixels (moet je natuurlijk wel effe checken of dat niet 0 is, want anders krijg je een deling door 0, en als ie 0 is is de kleur toch ongedefinieerd dus dan kun je net zo goed 0x8000 terug sturen)

Hij moet niet alleen met 1-bit transparantie overweg kunnen, maar ook met 8-bit. Dus het wordt nog iets moeilijker.

En mipmaps zijn alleen een performance hulpmiddel, ze zijn niet nodig om netjes te kunnen downscalen.

[Olaf van der Spek]

Op woensdag 16 januari 2002 10:03 schreef OlafvdSpek het volgende:
Die witte pixels zijn 0% opaque, dus die zie je niet in het origineel. Die mogen in het resultaat dus ook geen invloed hebben.

Ik bedoel dat de kleur geen invloed mag hebben op het resultaat. De alpha waarde natuurlijk wel.

[.oisyn]

godver, ik had een verhaal getiept maar door die *KUT* code #55 is het weg

[.oisyn]

anyway, ik zei dus dat je ipv de 4 pixels die naast elkaar liggen, met hele rijen van pixels moet gaan werken, die allemaal in het gebied liggen wat je samplet

De pixels langs de rand krijgen allemaal de factor van de oppervlakte die in het gebied ligt, en de tussenliggende pixels een factor 1
Je telt alle kleur * factor bij elkaar op, en uiteindelijk deel je door de totale oppervlakte van het gebied

Alleen dan zit je nog met die alpha... Dat zou je natuurlijk op kunnen lossen door kleur * alpha * factor te doen, waarbij alpha een waarde is tussen 0 en 1
Aan het eind deel je de uiteindelijke kleurwaarde dan door de uiteindelijke alpha (waarbij alpha dus weer tussen 0 en 1 ligt)

[Verwijderd]

Je kunt ook gewoon FreeImage aan je app linken, een of 2 methods aanroepen en de weerga aan formats scalen, bewerken etc. Er zijn al genoeg wielen uitgevonden jongens

(of: DevIL, als je het ECHT niet meer weet )

[Olaf van der Spek]

Ik heb geen zin een hele lib te linken voor slechts een functie. En die lib is ook nog eens GPL, niet LGPL.

[Olaf van der Spek]

OiSyN, ik denk trouwens dat jouw code fout loopt met floor en ceil. Als de waarde namelijk precies een geheel getal is, geven ceil en floor beide die waarde terug. Dan is f altijd 0 en heb je dus een (zwarte) transparante pixel.

Ik heb nog eens zitten nadenken en ik denk dat ik nu weet waarom wat ik 'wil' eigenlijk niet zomaar kan.

Het probleem zit hem in het interpoleren van alpha. Als je alpha gebruikt voor dichtheid kun je gewoon volgens jouw code interpoleren.
Maar als je alpha gebruikt zoals ik doe (1-bit voor transparancy), dan moet je eigenlijk niet interpoleren en alleen 0% en 100% gebruiken (denk ik).

[.oisyn]

Op vrijdag 18 januari 2002 13:01 schreef OlafvdSpek het volgende:
OiSyN, ik denk trouwens dat jouw code fout loopt met floor en ceil. Als de waarde namelijk precies een geheel getal is, geven ceil en floor beide die waarde terug. Dan is f altijd 0 en heb je dus een (zwarte) transparante pixel.

goed punt! En het is ook zo dat je eigenlijk 1 - (x - floor (x)) had moeten nemen... wat ook gelijk voor de oplossing zorgt:
linksboven is 1 - (x - floor (x)) en 1 - (y - floor )
rechtsonder is x - floor (x) en y - floor

ik zal mijn code even editten hierboven

Ik heb nog eens zitten nadenken en ik denk dat ik nu weet waarom wat ik 'wil' eigenlijk niet zomaar kan.

Het probleem zit hem in het interpoleren van alpha. Als je alpha gebruikt voor dichtheid kun je gewoon volgens jouw code interpoleren.
Maar als je alpha gebruikt zoals ik doe (1-bit voor transparancy), dan moet je eigenlijk niet interpoleren en alleen 0% en 100% gebruiken (denk ik).

die 1 bits is meer gewoon afronding... Als je het interpoleert en later weer terug zet naar 1 bits krijg je toch weer gewoon 0% en 100%. Alleen tussendoor gebruik je floating point getallen voor nauwkeurige berekening. Ik denk dat als je gewoon met die ene bit gaat werken dat je dan foute resultaten krijgt (of je moet weer extra code aanmaken om rekening te houden met fouten enzo)

[.oisyn]

"Helaas, je mag een bericht maar tot maximaal 24 uur na posten wijzigen."

hmmz

dan maar zo:

code:

unsigned short getPixel (float x, float y)
{
    float lx = x - floor (x), ly = y - floor (y);
    float ux = 1.f - lx, uy = 1.f - ly;
    float f, r, g, b, a;
    unsigned short c;

    c = buffer[(int)uy * width + (int)ux];
    f = ux * uy;
    r = (float)(c & 0x001f) * f;
    g = (float)(c & 0x03e0) * f;
    b = (float)(c & 0x7c00) * f;
    a = (float)(c & 0x8000) * f;

    c = buffer[(int)uy * width + (int)lx];
    f = lx * uy;
    r += (float)(c & 0x001f) * f;
    g += (float)(c & 0x03e0) * f;
    b += (float)(c & 0x7c00) * f;
    a += (float)(c & 0x8000) * f;

    c = buffer[(int)ly * width + (int)ux];
    f = ux * ly;
    r += (float)(c & 0x001f) * f;
    g += (float)(c & 0x03e0) * f;
    b += (float)(c & 0x7c00) * f;
    a += (float)(c & 0x8000) * f;

    c = buffer[(int)ly * width + (int)lx];
    f = lx * ly;
    r += (float)(c & 0x001f) * f;
    g += (float)(c & 0x03e0) * f;
    b += (float)(c & 0x7c00) * f;
    a += (float)(c & 0x8000) * f;

    return (unsigned short)((int)r & 0x001f) | ((int)g & 0x03e0) |
         ((int)b & 0x7c00) & ((int)a & 0x8000);
}

[Orphix]

ennuh komt dit nou in de codebase te staan?