Apache OpenOffice (AOO) Bugzilla – Issue 60368
Toolbar icons should not have gamma correction
Last modified: 2009-04-23 13:53:17 UTC
With .png files, comes the possibility to include gamma correction. While useful for graphic design and photo images, this can lead to problems with icon style graphics. Icons are often drawn as paletted images, where the RGB values are taken to be absolute. Furthermore, it is well established that applications (such as Photoshop) can produce inappropriate gamma chunks. Having surveyed the icons in 'default_images', there are many icons with and without gamma data. Those that have, sometimes have the gamma data for a Mac (0.65909) or PC (0.45455) or other- although the 'standard' colours (e.g. Sun Purple) have the same RGB values. Currently as icons are read in (pngread.cxx?), the gamma is being adjusted where indicated. With the increased ability to theme the UI (see i36518), it is likely that problems (even if subtle) will arise due to gamma correction. This is illustrated in the attached screenshots. I propose that for UI images (icons and such), no gamma correction is applied- this will ensure icons are in fact more consistent and will improve efficiency (less decoding). Other colour correction chunks should also be ignored: cHRM - Primary chromaticities sRGB - Standard RGB color space iCCP - Embedded ICC profile Regards, Andrew Reference last paragraph (first hit on Google...): http://hsivonen.iki.fi/png-gamma/
Created attachment 33110 [details] Screenshot of tool bar icon (cut) with NO gamma
Created attachment 33111 [details] Screenshot of tool bar icon (cut) with gamma applied
>pl: Now your job?
My first idea would be that icons should show the same way they were designed and if they were designed with gamma, then we probably should use that. However that may be a matter of debate. Setting sts and cj on CC so they can add their opinion. pl->hdu: you said png import is yours nowaday.
>pl The problem is that rarely (with icons) is gamma set by *design*. It is often just some default value that the bitmap editing software sets. And that's the issue: different software, different gamma. I don't think I've ever met someone who sets the gAMA chunk of a png to a certain calibrated value... in fact most people are unaware of any gAMA chunk. IMHO, it is better to have consistency bewteen icons on one system, at the risk of differences across systems. I think people are more likely to notice colour differences on icons on the same toolbar, than comparing their Mac and PC display outputs... Cheers, Andrew
Setting status to New (confirmed), to remove this Issue from QA Triage list. Hope that's ok. Regards, Andrew
.
*** Issue 63485 has been marked as a duplicate of this issue. ***
set target 3.x
*** Issue 101237 has been marked as a duplicate of this issue. ***
Confirming KA's observation that most of OOo's icons request gamma correction @sts: you can check which icons still have gAMA chunks by running fgrep -c gAMA *.png | grep -v ":0" in your image directory. Getting rid of toolbar icon gammas would speedup the boot by about 2% too.
Is it possible to target for 3.2 then, as per Issue 101237 ? If this causes problems with the stock Sun designs, it will certainly confuse external icon designers. Also there is a performance benefit of skipping non-essential PNG chunks when rendering for the UI.
Set target to 3.2 and reassigned to SJ to edit the filter code appropriately. My conclusion is to ignore the Gamma value during import. Since I expect 99+ % of our customer base not using calibrated equipment and since differences with toolbar icons are only really visible by a side-by-side comparison on the same screen, there schouldn't be any major issues by ignoring this value. Ignoring the gamma value has also the benefit for people with lower eye perception that the contrast will be slightly enhanced, making it easier for them to recognize the content of the icon. In addition, it seems just to be wrong to recalculate pixels using the gamma value for our purposes taking other products into account.
set issue type to 'Defect'
Created attachment 61752 [details] screenshot
Created attachment 61753 [details] screenshot
AFAIK other important legacy office suites are using the gamma information, so ignoring gamma everywhere is not a good for compatibility reasons. Anyway here is the patch to disable PNG gamma everywhere: --- vcl/source/gdi/pngread.cxx +++ vcl/source/gdi/pngread.cxx @@ -386,3 +386,5 @@ BitmapEx PNGReaderImpl::GetBitmapEx( const Size& rPreviewSizeHint ) +#if 0 // #i60368# ignore gamma correction for all PNGs if ( mbIDAT == FALSE ) // the 'IDAT' and also the ImplGetGamma(); // 'PLTE'(if available ) +#endif
Seconding hdu. Please make ignoring the gAMA chunk optional, I'd definitely like to keep it for document images.
Set issue to 'started'. SJ is currently working on the task, giving the filter a flag to use Gamma or not. IMO, everything outside document graphics (e.g. toolbars icons, menu icons etc.) should ignore Gamma by default, which also gives the improvement in startup performance, already mentioned by Herbert. How to set the default for 'document' PNGs seems to be subject of further discussions, but the current behaviour in documents (with Gamma) will be kept until we'll have found a final solution. I suggest to set up a small chat with everybody on cc (in the first run) and announcing it on the mailing list, when SJ will have finished his current work.
This has been fixed now in cws[impress171] with rev 271169. The gamma value is ignored when loading the image lists (which includes toolbar and menu icons), nothing is changed when displaying document images.