You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Peter Becker <pb...@dstc.edu.au> on 2003/09/12 13:56:17 UTC
Encoding PNGs without gAMA
[was: Re: Text rendering changes after upgrade to 1.5]
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: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Encoding PNGs without gAMA
Posted by Peter Becker <pb...@dstc.edu.au>.
Thomas DeWeese wrote:
[...]
>> Two little questions from someone not really knowing about PNG: is
>> there absolutely no situation you might want to set a 2.2 gamma
>> without wanting sRGB?
>
>
> The PNG specification requires that the gamma and chrm chunks be set
> appropriately for sRGB. Remember sRGB is _a_ colorspace it is not a
> family of colorspaces. It would be wrong to say you have an image in
> sRGB with a gamma of 2.0 - the image would not be in sRGB it might share
> the chromaticities of sRGB but if the rendering curve is different it is
> not the same colorspace.
I was thinking the other way round: setting the 2.2, but not the sRGB.
It seems the new code would allow that.
>
>> And won't you have the same problem as the spec that 2.2 might not
>> always be the same as 2.2 -- e.g. if someone cast a float to a
>> double? Just try this:
>>
>> System.out.println(2.2 == 2.2f);
>>
>> Intuitively I'd skip the extra rule for 2.2 -- no gamma given is
>> already sRGB. Two ways to achieve the same seem to just create
>> confusion -- esp. if one of the methods might not always work.
>
>
> I decided to go this way for cases where someone did not want the
> sRGB chunk to be written but they still wanted sRGB chrm and gama
> chunks.
Exactly.
>
> For constants I don't worry so much about cases like the above also all
> Key values will be mapped to a float along the way anyways.
Hmmm.... how well defined is the mapping from double to float? Java
defines most of these things, but not necessarily all. Is new Float(2.2)
a constant across platforms? Would a version compiled on ACME JDK 1.7 on
OS W (can't use X anymore) work on EMCA JDK 2.3 on OS V? I just wouldn't
want to rely on these things ;-) Probably even not if I find some rule
in the spec -- it would be too likely that I am on a lonely side if a
JDK doesn't follow the spec properly.
Anyway -- the new code works like a charm for me and I am getting too
academic. Thanks for the fix.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Encoding PNGs without gAMA
Posted by Thomas DeWeese <Th...@Kodak.com>.
Peter Becker wrote:
> Thomas DeWeese wrote:
>
>> Peter Becker wrote:
>>
>>> Me again,
>>>
>>> I should first try then talk. I managed to get the results I wanted
>>> but there are some small issues.
>>>
>>> (a) it might be better to use transcoding hints instead of the extra
>>> contructor. If I understand the code right it would be consistent to
>>> set a mapping from something like KEY_PNG_ENCODING_PARAMETERS to the
>>> parameter object.
>>
>>
>>
>> It would certainly be more consistent to use a hint. Although this is
>> a _very_ specific hint - so it might not matter that much.
>>
>>> (b) there is actually a KEY_GAMMA used in the code. It just doesn't
>>> work since the transcoder always declares sRGB as intentional and
>>> that has the consequence of turning gamma on. Somehow this
>>> combination of offering KEY_GAMMA as hint and _always_ assuming sRGB
>>> is intentional seems inconsistent to me
>>
>>
>>
>> I agree, this is a bug. What I have done is:
>> If KEY_GAMMA is not present or is 2.2 just set sRGBIntent.
>> else If KEY_GAMMA is == '0' don't generate gamma chunk do generate
>> cHRM (with default sRGB value) chunk.
>> else don't output sRGBIntent but output gamma (with given value) and
>> cHRM (with default sRGB value) chunks.
>>
>> I'll deliver this later today. This should let you do what you want.
>>
> Sounds good to me. I was thinking along giving more options by offering
> tweaking the whole parameter set, but I suspect that might be overkill.
It is a bit of overkill also as you pointed out some of the fields
like pixel size are difficult to provide properly.
> Two little questions from someone not really knowing about PNG: is there
> absolutely no situation you might want to set a 2.2 gamma without
> wanting sRGB?
The PNG specification requires that the gamma and chrm chunks be set
appropriately for sRGB. Remember sRGB is _a_ colorspace it is not a
family of colorspaces. It would be wrong to say you have an image in
sRGB with a gamma of 2.0 - the image would not be in sRGB it might share
the chromaticities of sRGB but if the rendering curve is different it is
not the same colorspace.
>And won't you have the same problem as the spec that 2.2
> might not always be the same as 2.2 -- e.g. if someone cast a float to a
> double? Just try this:
>
> System.out.println(2.2 == 2.2f);
>
> Intuitively I'd skip the extra rule for 2.2 -- no gamma given is already
> sRGB. Two ways to achieve the same seem to just create confusion -- esp.
> if one of the methods might not always work.
I decided to go this way for cases where someone did not want the
sRGB chunk to be written but they still wanted sRGB chrm and gama
chunks.
For constants I don't worry so much about cases like the above also all
Key values will be mapped to a float along the way anyways.
> But in any case that wouldn't affect me :-)
>
> Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Encoding PNGs without gAMA
Posted by Peter Becker <pb...@dstc.edu.au>.
Thomas DeWeese wrote:
> Peter Becker wrote:
>
>> Me again,
>>
>> I should first try then talk. I managed to get the results I wanted
>> but there are some small issues.
>>
>> (a) it might be better to use transcoding hints instead of the extra
>> contructor. If I understand the code right it would be consistent to
>> set a mapping from something like KEY_PNG_ENCODING_PARAMETERS to the
>> parameter object.
>
>
> It would certainly be more consistent to use a hint. Although this is
> a _very_ specific hint - so it might not matter that much.
>
>> (b) there is actually a KEY_GAMMA used in the code. It just doesn't
>> work since the transcoder always declares sRGB as intentional and
>> that has the consequence of turning gamma on. Somehow this
>> combination of offering KEY_GAMMA as hint and _always_ assuming sRGB
>> is intentional seems inconsistent to me
>
>
> I agree, this is a bug. What I have done is:
> If KEY_GAMMA is not present or is 2.2 just set sRGBIntent.
> else If KEY_GAMMA is == '0' don't generate gamma chunk do generate
> cHRM (with default sRGB value) chunk.
> else don't output sRGBIntent but output gamma (with given value) and
> cHRM (with default sRGB value) chunks.
>
> I'll deliver this later today. This should let you do what you want.
>
Sounds good to me. I was thinking along giving more options by offering
tweaking the whole parameter set, but I suspect that might be overkill.
Two little questions from someone not really knowing about PNG: is there
absolutely no situation you might want to set a 2.2 gamma without
wanting sRGB? And won't you have the same problem as the spec that 2.2
might not always be the same as 2.2 -- e.g. if someone cast a float to a
double? Just try this:
System.out.println(2.2 == 2.2f);
Intuitively I'd skip the extra rule for 2.2 -- no gamma given is already
sRGB. Two ways to achieve the same seem to just create confusion -- esp.
if one of the methods might not always work.
But in any case that wouldn't affect me :-)
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Encoding PNGs without gAMA
Posted by Thomas DeWeese <Th...@Kodak.com>.
Peter Becker wrote:
> Me again,
>
> I should first try then talk. I managed to get the results I wanted but
> there are some small issues.
>
> (a) it might be better to use transcoding hints instead of the extra
> contructor. If I understand the code right it would be consistent to set
> a mapping from something like KEY_PNG_ENCODING_PARAMETERS to the
> parameter object.
It would certainly be more consistent to use a hint. Although this is
a _very_ specific hint - so it might not matter that much.
> (b) there is actually a KEY_GAMMA used in the code. It just doesn't work
> since the transcoder always declares sRGB as intentional and that has
> the consequence of turning gamma on. Somehow this combination of
> offering KEY_GAMMA as hint and _always_ assuming sRGB is intentional
> seems inconsistent to me
I agree, this is a bug. What I have done is:
If KEY_GAMMA is not present or is 2.2 just set sRGBIntent.
else If KEY_GAMMA is == '0' don't generate gamma chunk do generate
cHRM (with default sRGB value) chunk.
else don't output sRGBIntent but output gamma (with given value) and
cHRM (with default sRGB value) chunks.
I'll deliver this later today. This should let you do what you want.
> Apart from these two potential issues I found a solution that works for
> me and shouldn't hurt anyone else. Here is the diff -- it looks bigger
> than it is since I moved a chunk of code into an if-statement, thus
> increasing indentation:
>
> =========================
> Index: PNGTranscoder.java
> ===================================================================
> RCS file:
> /home/cvspublic/xml-batik/sources/org/apache/batik/transcoder/image/PNGTranscoder.java,v
>
> retrieving revision 1.18
> diff -u -r1.18 PNGTranscoder.java
> --- PNGTranscoder.java 8 Aug 2003 11:39:25 -0000 1.18
> +++ PNGTranscoder.java 12 Sep 2003 12:45:43 -0000
> @@ -73,6 +73,10 @@
> * @version $Id: PNGTranscoder.java,v 1.18 2003/08/08 11:39:25 vhardy Exp $
> */
> public class PNGTranscoder extends ImageTranscoder {
> + /**
> + * Stores the encoding parameters if fixed parameters are used.
> + */
> + private PNGEncodeParam encodeParams = null;
>
> /**
> * Constructs a new transcoder that produces png images.
> @@ -80,6 +84,14 @@
> public PNGTranscoder() {
> hints.put(KEY_FORCE_TRANSPARENT_WHITE, Boolean.FALSE);
> }
> + + /**
> + * Constructs a transcoder using a fixed parameter set.
> + */
> + public PNGTranscoder(PNGEncodeParam parameters) {
> + this();
> + this.encodeParams = parameters;
> + }
>
> /**
> * Creates a new ARGB image with the specified dimension.
> @@ -155,26 +167,32 @@
> img = IndexImage.getIndexedImage(img,1<<n);
> }
>
> - PNGEncodeParam params = PNGEncodeParam.getDefaultEncodeParam(img);
> - if (params instanceof PNGEncodeParam.RGB) {
> - ((PNGEncodeParam.RGB)params).setBackgroundRGB
> - (new int [] { 255, 255, 255 });
> - }
> + PNGEncodeParam params;
> + if(this.encodeParams == null) {
> + params = PNGEncodeParam.getDefaultEncodeParam(img);
> +
> + if (params instanceof PNGEncodeParam.RGB) {
> + ((PNGEncodeParam.RGB)params).setBackgroundRGB
> + (new int [] { 255, 255, 255 });
> + }
>
> - // If they specify GAMMA key then use it otherwise don't
> - // write a gAMA chunk, (default Gamma=2.2).
> - if (hints.containsKey(KEY_GAMMA)) {
> - params.setGamma(((Float)hints.get(KEY_GAMMA)).floatValue());
> - }
> -
> - // We always want an sRGB chunk and Our encoding intent is
> - // perceptual
> - params.setSRGBIntent(PNGEncodeParam.INTENT_PERCEPTUAL);
> -
> - float PixSzMM = userAgent.getPixelUnitToMillimeter();
> - // num Pixs in 1 Meter
> - int numPix = (int)((1000/PixSzMM)+0.5);
> - params.setPhysicalDimension(numPix, numPix, 1); // 1 means
> 'pix/meter'
> + // If they specify GAMMA key then use it otherwise don't
> + // write a gAMA chunk, (default Gamma=2.2).
> + if (hints.containsKey(KEY_GAMMA)) {
> +
> params.setGamma(((Float)hints.get(KEY_GAMMA)).floatValue());
> + }
> +
> + // We always want an sRGB chunk and Our encoding intent is
> + // perceptual
> + params.setSRGBIntent(PNGEncodeParam.INTENT_PERCEPTUAL);
> +
> + float PixSzMM = userAgent.getPixelUnitToMillimeter();
> + // num Pixs in 1 Meter
> + int numPix = (int)((1000/PixSzMM)+0.5);
> + params.setPhysicalDimension(numPix, numPix, 1); // 1 means
> 'pix/meter'
> + } else {
> + params = this.encodeParams;
> + }
>
> try {
> PNGImageEncoder pngEncoder = new PNGImageEncoder(ostream,
> params);
> ======================================
>
> I'm happy to adjust this in case you don't like it.
>
> Peter
>
>
>
> Peter Becker wrote:
>
>> [was: Re: Text rendering changes after upgrade to 1.5]
>>
>> 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: batik-users-unsubscribe@xml.apache.org
>> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Encoding PNGs without gAMA
Posted by Peter Becker <pb...@dstc.edu.au>.
Me again,
I should first try then talk. I managed to get the results I wanted but
there are some small issues.
(a) it might be better to use transcoding hints instead of the extra
contructor. If I understand the code right it would be consistent to set
a mapping from something like KEY_PNG_ENCODING_PARAMETERS to the
parameter object.
(b) there is actually a KEY_GAMMA used in the code. It just doesn't work
since the transcoder always declares sRGB as intentional and that has
the consequence of turning gamma on. Somehow this combination of
offering KEY_GAMMA as hint and _always_ assuming sRGB is intentional
seems inconsistent to me
Apart from these two potential issues I found a solution that works for
me and shouldn't hurt anyone else. Here is the diff -- it looks bigger
than it is since I moved a chunk of code into an if-statement, thus
increasing indentation:
=========================
Index: PNGTranscoder.java
===================================================================
RCS file:
/home/cvspublic/xml-batik/sources/org/apache/batik/transcoder/image/PNGTranscoder.java,v
retrieving revision 1.18
diff -u -r1.18 PNGTranscoder.java
--- PNGTranscoder.java 8 Aug 2003 11:39:25 -0000 1.18
+++ PNGTranscoder.java 12 Sep 2003 12:45:43 -0000
@@ -73,6 +73,10 @@
* @version $Id: PNGTranscoder.java,v 1.18 2003/08/08 11:39:25 vhardy Exp $
*/
public class PNGTranscoder extends ImageTranscoder {
+ /**
+ * Stores the encoding parameters if fixed parameters are used.
+ */
+ private PNGEncodeParam encodeParams = null;
/**
* Constructs a new transcoder that produces png images.
@@ -80,6 +84,14 @@
public PNGTranscoder() {
hints.put(KEY_FORCE_TRANSPARENT_WHITE, Boolean.FALSE);
}
+
+ /**
+ * Constructs a transcoder using a fixed parameter set.
+ */
+ public PNGTranscoder(PNGEncodeParam parameters) {
+ this();
+ this.encodeParams = parameters;
+ }
/**
* Creates a new ARGB image with the specified dimension.
@@ -155,26 +167,32 @@
img = IndexImage.getIndexedImage(img,1<<n);
}
- PNGEncodeParam params = PNGEncodeParam.getDefaultEncodeParam(img);
- if (params instanceof PNGEncodeParam.RGB) {
- ((PNGEncodeParam.RGB)params).setBackgroundRGB
- (new int [] { 255, 255, 255 });
- }
+ PNGEncodeParam params;
+ if(this.encodeParams == null) {
+ params = PNGEncodeParam.getDefaultEncodeParam(img);
+
+ if (params instanceof PNGEncodeParam.RGB) {
+ ((PNGEncodeParam.RGB)params).setBackgroundRGB
+ (new int [] { 255, 255, 255 });
+ }
- // If they specify GAMMA key then use it otherwise don't
- // write a gAMA chunk, (default Gamma=2.2).
- if (hints.containsKey(KEY_GAMMA)) {
- params.setGamma(((Float)hints.get(KEY_GAMMA)).floatValue());
- }
-
- // We always want an sRGB chunk and Our encoding intent is
- // perceptual
- params.setSRGBIntent(PNGEncodeParam.INTENT_PERCEPTUAL);
-
- float PixSzMM = userAgent.getPixelUnitToMillimeter();
- // num Pixs in 1 Meter
- int numPix = (int)((1000/PixSzMM)+0.5);
- params.setPhysicalDimension(numPix, numPix, 1); // 1 means
'pix/meter'
+ // If they specify GAMMA key then use it otherwise don't
+ // write a gAMA chunk, (default Gamma=2.2).
+ if (hints.containsKey(KEY_GAMMA)) {
+
params.setGamma(((Float)hints.get(KEY_GAMMA)).floatValue());
+ }
+
+ // We always want an sRGB chunk and Our encoding intent is
+ // perceptual
+ params.setSRGBIntent(PNGEncodeParam.INTENT_PERCEPTUAL);
+
+ float PixSzMM = userAgent.getPixelUnitToMillimeter();
+ // num Pixs in 1 Meter
+ int numPix = (int)((1000/PixSzMM)+0.5);
+ params.setPhysicalDimension(numPix, numPix, 1); // 1 means
'pix/meter'
+ } else {
+ params = this.encodeParams;
+ }
try {
PNGImageEncoder pngEncoder = new PNGImageEncoder(ostream,
params);
======================================
I'm happy to adjust this in case you don't like it.
Peter
Peter Becker wrote:
> [was: Re: Text rendering changes after upgrade to 1.5]
>
> 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: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org