[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PNG pictures have gamma correction twice applied
From: |
Stefan Monnier |
Subject: |
Re: PNG pictures have gamma correction twice applied |
Date: |
Mon, 11 Nov 2002 11:58:13 -0500 |
> Now x_alloc_nearest_color is defined in src/xterm.c. It first calls
> gamma_correct on the function in question (which does the gamma
> correction with a very expensive floating point operation), then
> calls x_alloc_nearest_color_1, which does a costly operation of
> figuring out a closest color.
Have you checked whether this "costly operation" is actually done
in your case ? It should only happen if the XAllocColor fails, which
should never be the case in a 16bpp (or more) display.
> entirely bypassed the whole folderol, and I would guess that for the
> rest 10% of users with 8bit per pixel devices, some low quality
> fallback (such as getting 64 fixed colors for 8bit display devices)
> would still be appreciated more than the current slow behavior of
> images.
The reason for the "closest color" code is to deal with the situation
where the aren't enough color slots available. There might very well
not be 64 slots available.
I think this part of the code is OK, especially since I believe it is only
triggered in the very rare cases where it is needed.
But I agree that the lookup&gamma&caching is a bit strangely done and
is probably not ideal for displays with more than 256 colors. I believe
the code for lookup has a comment that says essentially the same thing.
But I also remember that some of that code was done to try and reduce the
amount of X traffic (there were many calls to XAllocColor or XLookupColor
or something like that).
I think the caching could be improved (to reduce X traffic), tho.
And bypassing this code for PNG would be a good idea since libpng should
do a good enough (better) job already.
Stefan