Thomas DeWeese wrote:
[...]
BTW: it still seems the gamma problem I have is still around. If you look at http://tockit.sf.net with Internet Explorer you will notice that the navigation PNGs are of a slightly different colour than the surrounding bits and pieces. I tracked that down once to the gamma value in the PNGs which seems to be ignored by most software but IE (e.g. the site looks good in Mozilla). Is there any new insight on how to avoid that problem?
From what you have said so far I would say it is a bug in what ever
other software you used to generate PNG files that they do not include
a gama chunk. You could hack Batik so it doesn't generate one but I
don't think this would be the right approach to take.
Hmmm... look at this page in IE: http://www.itee.uq.edu.au/~pbecker/batik/testColor.html
This is the Batik-rendered PNG on top of HTML background with exactly the same RGB values. And it is clearly rendered differently while Mozilla produces the same color. As does Adobe's viewer from the SVG.
If you think that Batik should remove the Gama chunk from the PNG files
that it creates than I strongly disagree, quoting from the PNG specification:
If the encoder does not know the image's gamma value, it should not write a gAMA chunk; the absence of a gAMA chunk indicates that the gamma is unknown.
In this case we know exactly what the gAMA is (all SVG output is in standard sRGB colorspace with a gama of 2.2) so we provide that information as the PNG standard says we should.
There was a bug reported that Batik produces a gamma value that is
off by one code value. I put in the code to fix this but didn't
'turn it on' because it causes all our test images to fail compairison
and it was a bad time to do that. However you might try turning that
on, xml-batik/sources/org/apache/batik/ext/awt/image/codec/PNGImageEncoder.java
line 556. This should not produce a visably different result, but
perhaps it does in IE. I would be interested in knowing if this fixes it.
There is also a gamma transcoding hint that you could try using. See batik.transcoder.image.PNGTranscoder line 214. This is not currently exposed from the application.
Aside from those options if you actually want to remove the generation of Gamma chunks for Batik you will have to hack it yourself (it is not something I will spend time on). If done well (i.e. made a comand line parameter etc, and you are willing to sign a contributors agreement) it would probably be accepted into Batik.
Hi Thomas,
I had a look at the code and so far I am up to this:
- org.apache.batik.ext.awt.image.codec.PNGEncodeParam does include the information on the gAMA value to use and if any is to use at all
- but in org.apache.batik.transcoder.image.PNGTranscoder, line 158 an instance of this class is create by a factory method getDefaultEncodeParam(Image), which is then used for the PNGImageEncoder
What I'd tend to do if this would be my code and I would be sure I grok it would be having a second constructor on the transcoder class that takes an intialized parameter object and stores it as member. A transcoder created this way would use the given parameters instead of the default ones. The major drawback of this approach is that the transcoder created would be insensitive to the image processed -- as opposed to the default version. But it seems reasonable to assume that if the caller created a particular parameter setting they know what they are doing.
Another option would be having a boolean member to toggle just the gAMA. More specific, but it would keep the sensitivity for the color depth. I don't know if there are other things one might want to tweak in the params object.
I'd tend to the first version: add member of PNGEncodeParam, add second constructor to set it and behave as before if member is null.
Comments? Shall I just try and send a patch if it works for me? Any prefered patch format?
Peter
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
