( arpi_esp | 2025. 05. 02., p – 00:53 )

Szerkesztve: 2025. 05. 02., p – 01:08

Szuper! Megneztem az algoritmust, de ez leginkabb csak rajzokra jo (ahol sok pixel pont ugyanolyan szinu), foto jellegu kepeknel szerintem ez nagyobb lesz mint BMP-ben :)

A PNG-ben vannak filterek amik differencialnak akar az elozo pixel sorhoz is, es az eredmenyt huffman kodolja, az se kozeliti a jpeget, de azert az fotoknal is hatasos valamennyire.

En 20 eve jpeg-bol csinaltam egy sajat egyszerusitett verziot ami YUV helyet RGB-t tarolt, gyorsan lehetett parsolni (huffman/idct megvolt de a jpeg-fele markereket es egyeb bonyolitast kihagytam teljesen) es tamogatott alpha-t is, megpedig ugy hogy blokkonkent (8x8 pixel) tarolta 1 biten hogy van-e atlatszosag/alpha, a 0=nem (RGB volt tarolva csak) es ha 1=igen akkor a kovetkezo biten hogy teljesen atlatszo-e a blokk (ilyenkor nem is tarolt mast) vagy csak reszben, akkor RGBA data jott. igy a dekoder tudta optimalizalni blokkonkent a blendinget, csak a reszben atlatszoknal kellett a hatterrel mixelnie, kulonben vagy siman felulirta a hattaret vagy beken hagyta teljes egeszeben. mivel a blokkok max 5-10%-a volt reszben atlatszo ezzel sok cpu idot nyertunk. meg azzal is hogy a hatternel nem kellett semmit dekodolni meg blendelni/irni, csak atugrani.