fre 2019-02-15 klockan 16:45 +0000 skrev Kornel: > > > 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?
Aha. Yeah then a different encoder would be the appropriate solution. It's neat that you can do this with LZW /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
