Hello Andrew,
One final thought: we could implement some of these standard colour spaces
by subclassing ColorSpace directly without the use of any underlying
colour profile. This would be more accurate than lcms in many cases, and
might even be faster in some.
There is a drawback of such approach. The color spaces implemented
directly couldn't be effectively used in ColorConvertOp operation with
buffered images. Because it's impossible to link such transforms with
icc ones (our default sRGB color space among them). So, the color
transformation would end up with per-pixel color transformation of the
whole image. Which is unacceptable slow.
Also, there could be some problems with backward compatibility
concerning ColorConvertOp. Because of ColorConvertOp(ICC_Profile[]
profiles, RenderingHints hints) constructor. Someone could use it
following way:
ColorConvertOp(new ICC_Profile[]
{((ICC_ColorSpace)ColorSpace.getInstance(ColorSpace.CS_PYCC).)getProfile()},
null)
Best Regards,
Alexey
So, where should I send these profiles?
Andrew.
Andrew Haley wrote:
Andrew Haley wrote:
Just a heads-up: I'm working on Bug 6523403, Need to provide lcms
library with PYCC and LINEAR_RGB OS ICC profiles. I'm also looking
at the causes of Bug 6523402, Some quality problems with GRAY, PYCC
and CIEXYZ color spaces with lcms library
I have created a LINEAR_RGB profile using the same primaries as the
lcms sRGB profile, and I have verified that it's compatible with
the Kodak-provided one in the proprietary JDK. The PYCC profile
will take a little longer, and I've started working on that.
Just a bit more information on my progress. I've created a PYCC profile
based on specs from Kodak, but I'm being hampered by some bugs in lcms,
which at the present time can't even get the sRGB primaries exactly
right.
I note that this is already a known bug in OpenJDK, # 6523402. I'm
investigating.
Andrew.
