On 2/15/19, Kornel <mailingl...@geekhood.net> wrote: > >>> 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? >
Into GIF encoder. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
