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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
