>> Alternatively, would it be OK to create a separate codec just for >> lossy compression? I would create a new GIF codec, define it under a >> new name, and declare it always takes AV_PIX_FMT_RGB24 or >> AV_PIX_FMT_RGBA. Is that a good approach? > > This sounds more like something that belongs in libswscale (RGBA -> > PAL8 conversion) or could be done with a filter. An option like > ImageMagick's -fuzz could be added to the PAL8 quantizer in sws
Unfortunately, the lossy technique depends on a layering violation. The lossy compression alters each pixel in the image based on current, precise state of the LZW dictionary. Without doing both LZW and remapping at the same time I don't have information required to make the image optimally compressible. At best I could simulate LZW compression in swscale just for the purpose of remapping/dithering filter, and then expect the GIF codec to LZW-compress the remapped image again. However, that approach doesn't work in practice: the second LZW encoder pass ends up making different decisions than the first one, falls out of sync with the optimal lossy pattern, and ends up creating a large file. Given the constraint of true-color input and LZW integrated in one algorithm, where's the best place to put that code? -- Kind regards, Kornel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
