Re: [FFmpeg-devel] Rework color quantization in palette{gen,use}

[Soft Works <softworkz@hotmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3327 bytes --]



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Clément Bœsch
> Sent: Tuesday, November 8, 2022 10:08 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Rework color quantization in
> palette{gen,use}
> 
> On Sun, Nov 06, 2022 at 07:46:38PM +0000, Soft Works wrote:
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Clément Bœsch
> > > Sent: Saturday, November 5, 2022 4:26 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: [FFmpeg-devel] Rework color quantization in
> palette{gen,use}
> > >
> > > Hi,
> > >
> > > This patchset essentially fixes a few core problems in these
> filters
> > > and
> > > switches to a perceptual model.
> > >
> > > I've generated a report for each key commit on this (temporary)
> page:
> > > http://big.pkh.me/pal/ (warning: heavy page, ~500M; I did try to
> add
> > > some lazy
> > > loading of the images but I'm not sure it's actually working as
> > > expected).
> >
> > Comparing the results for the known and simple "rainbow O" example
> reveals
> > that the proposed implementation seems to be even inferior to the
> current
> > code and even farther away from what is possible to achieve:
> >
> > https://gist.github.com/softworkz/e310e3c84a338f98977d70b09e3e3f4f
> 
> The pngquant file on this page has 373 unique colors, and the
> transparency
> is fake (the checkerboard is opaque white & grey). I think there is a
> mistake here.

Hi Clement,

I'm sorry about the confusion. The files in both Gists were created
in the same way: Opened the result image in PhotoShop, set the view
size to 400% and then created a screenshot and pasted into the Gist.
The reason I did it that way was that GitHub seemed to do its own
image "optimization" and I wanted to rule out any such effects and
just let others see what I see.

I couldn't find the original result from pngquant, but I have attached
the result from the elbg filter which is almost of the same quality.

For completeness, I'm also including the recent comparison, but it 
seems you're already on track in this regard.


> WRT the regression after the patch, I confirm that there is a problem
> related to the dithering. If you try with dither=none or even
> dither=bayer, you'll observe that the colors are much better. I will
> update the results page at some point to include that file.

That would be great. Maybe you could also find another "simple" example 
like with large-scale gradients rather than being so strongly colored
like the others?


Then I'd have a question about your file07 example. Is this the 
original file or did I mix something up?

http://big.pkh.me/pal/output/0-current/file07/cfg00/0-ref.png

I'm wondering because the image is full or weird artifacts at the 
edges of the green (and other) leafes.


> Now indeed the sierra dithering (and probably the other of the same
> type)
> are somehow spreading way too strongly, it's unclear to me yet but
> that
> might be a bug I introduced. I'll investigate, thanks.

Yup, okay, thanks.

PS: I'd be curious what you think about the elbg image...

Thanks,
softworkz





[-- Attachment #2: out_elbg8.zip --]
[-- Type: application/x-zip-compressed, Size: 4813 bytes --]

[-- Attachment #3: out_pngs.zip --]
[-- Type: application/x-zip-compressed, Size: 9998 bytes --]

[-- Attachment #4: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".