Načítání PNG pro pluginy

[Jan Patera]

Nechce se mi do problematiky investovat další čas, dnešní den je až až.

Souhlasim, ze by tym Altapu mel venovat cas spise na veci pro spravu souboru (web firmy, ...) nez detailum nacitani PNG obrazku v pluginech.

[Jan Rysavy]

Pouze poznámka k tomu, proč jsme především celé PNG do Salamandera zavedli. Salamander ukládá ikonky pluginů do konfigurace (výrazně to zrychluje start aplikace). Konfigurace je momentálně v Registry a my se snažíme její velikost držet na únosné míře. Nově potřebujeme ikonky ukládat s alpha transparencí, takže PNG byl vyhovující kandidát. Publikování funkcionality do pluginů je už jen důsledek.

Určitě bychom celou věc měli udržet pod kontrolou kvůli časovým nákladům. Pokud jeden plugin z deseti bude potřebovat "speciální servis", není problém přilinkovat PNGLite. Zbylých 9 pluginů by se mělo obejít s tím, co Salamander bude poskytovat.

Promyslím a napíšu reakci na tu hromadu dotazů.

[zarevak]

Souhlasim, ze by tym Altapu mel venovat cas spise na veci pro spravu souboru (web firmy, ...) nez detailum nacitani PNG obrazku v pluginech.

Souhlas

Omlouvám se za dlouhé příspěvky. Ve zkratce: Metody jsou super, jen je potřeba doplnit dokumentaci ohledně možných formátů bitmap. (Aby plugin věděl, které formáty bitmap může očekávat)

V bodech:

1) Není třeba měnit napsané metody či přídávat ppvBits parametr. Pomocí funkce GetObject() lze z HBITMAP získat všechny potřebné informace

2) Zajímalo mne, jak se metody vyrovnají s různými druhy PNG souborů? Jaké formáty bitmap různé formáty PNG generují? Které PNG jsou či nejsou povolené?

3) Přednásobení Alpha není třeba. Jen pokud by byl čas, tak umožnit pomocí flagů. Plugin z odděleného Alpha kanálu přednásobené hodnoty vyrobí kdykoliv.

4) Bylo by vhodné, kdyby indexované a greyscale PNG metoda vracela jako indexované bitmapy s paletou. Pro mé použití mi však převod na 24/32-bit bitmapu nevadí.

5) Pokud budou popsány možné formáty bitmap, které metoda generuje, tak není třeba již nic měnit (plugin si převody zajistí). Jen mne napadlo, že by metoda mohla umožnit pomocí flagu automaticky převést všechny PNG na jeden 24/32-bit formát pro jednoduší práci v pluginech.

6) DiskMapa: Popisoval jsem možné řešení formátu polštářků. Jedná se pouze o žádost o názor. Není třeba tím trávit čas

[Jan Rysavy]

Vracený DIB vypadá následně:

Code: Select all

HDC hMemDC = HANDLES(CreateCompatibleDC(NULL));
BITMAPINFOHEADER bmhdr;
memset(&bmhdr, 0, sizeof(bmhdr));
bmhdr.biSize = sizeof(bmhdr);
bmhdr.biWidth = png->width;
bmhdr.biHeight = -1 * png->height;  // top-down
bmhdr.biPlanes = 1;
bmhdr.biBitCount = 32;
bmhdr.biCompression = BI_RGB;
void *lpMemBits = NULL;
HBITMAP hMemBmp = HANDLES(CreateDIBSection(hMemDC, (CONST BITMAPINFO *)&bmhdr, 
                              DIB_RGB_COLORS, &lpMemBits, NULL, 0));

Případně DDB:

Code: Select all

HDC hDesktopDC = HANDLES(GetDC(NULL));
HBITMAP hNonDIBBmp = HANDLES(CreateCompatibleBitmap(hDesktopDC, bmpInfo.bmWidth, bmpInfo.bmHeight));

PNG obsahující palety se tedy načítají, ale převedou do zmíněného formátu.

Ohledně čtených formátů PNG stále platí:

Code: Select all

if(png->color_type == PNG_INDEXED && png->depth != 8)
  return PNG_NOT_SUPPORTED;

if(png->depth != 8 && png->depth != 16)
  return PNG_NOT_SUPPORTED;

if(png->interlace_method)
  return PNG_NOT_SUPPORTED;

Více viz kompletní zdrojáky upravené PNGLite.
Navíc přiznávám, že png->depth == 16 jsem netestoval, takže bychom spíš měli 16b považovat za nepodporované.
tRNS chunk umíme načíst (v těch 16b to zřejmě nebude chodit).

Pokud se ukáže, že bychom měli podporovat něco dalšího, nebude problém současné metody rozšířit.
Nerad bych do toho momentálně investoval čas (to co jsme potřebovali knihovna umí, vylepšovat určitě možné je).

[zarevak]

Super! Děkuji za podporu PNG a za odpověď.

PNG využiji určitě ve dvou svých pluginech a pravděpodobně i v DiskMapě na polštářky (což jsou 3 pluginy z 5). Ve všech mi současné řešení vyhovuje (hlavně to, že na úrovni pluginu mne čeká jen jeden 32-bit formát, se kterým musím počítat)

Přestože jsem v prvním příspěvku žádal načítání PNG z paměti pro CGUIIconList, tak přidáním nového objektu CSalamanderPNG považuji pro mne otázku podpory PNG za vyřešenou

[Jan Rysavy]

CGUIIconList jsem o načítání PNG z paměti rozšířil také, byla to otázka pár desítek minut (interně podpora existovala).
Pokud vznikne během nasazení potřeba stávající funkcionalitu kolem PNG rozšiřovat, rádi se na to podíváme.

[zarevak]

Díky.

Ještě jedna malá otázečka: jak je to s přednásobením podle Alpha kanálu? (ptám se pro upřesnění - zatím pro NEpřednásobnásobené hodnoty využítí nemám)

Pokud data budeme chtít dále zpracovávat (barevně tónovat, případně kreslit pomocí jiných metod), hodilo by se nechat RGB složky zachovány v rozsahu 0 až 255. Asi bych pro potlačení přednásobení zavedl další flag. Samozřejmě pak nebud možné na vrácený handle přímo zavolat AlphaBlend API.

Z tohohle chápu, že hodnoty jsou přednásobené...

[Jan Rysavy]

Přednásobení lze povolit pomocí flagu.