DataBuffer, ColorModels and SampleModels

[Alexey Ushakov]

Hello Ben,

Please see my answers bellow.

LOUD, Ben wrote On 14.05.2007 20:50,:

> I thought I'd give it a go as I was curious to if your performance 
> claims were true. I compared Classpath vs JDK6 RI, and sure enough, 
> the performance of the Classpath implementation was indeed hundreds of 
> times faster. It's much too significant to be JNI overhead.
>  
> So I had a look at the Classpath code, the implementation in 
> GrayScaleConverter is trivial, just a couple of lines, (no need to use 
> tone reproduction curves or matrices at all) Comparing it to equations 
> (1.2a) and (1.2b) in the w3c sRGB spec 
> (http://www.w3.org/Graphics/Color/sRGB), it would seem to be correct. 
> I modified it slightly so that the conversion expression was done 
> using all doubles and used StrichMath.pow, but still results were 
> consistently only accurate with JDK6 to around 2 decimal places (I'd 
> argue thats a very significant error for double precision math).
>
> I tested conversions between various combinations of color spaces and 
> there were differences every time, and given that the JDK6 version 
> takes hundreds of times longer, it must be doing something far more 
> complex than these trivial equations. 
>
> An interesting note:
>  
> float[] xyz = { x, y, z };
> ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_CIEXYZ);
> float[] xyz2 = cs.toCIEXYZ(xyz);
>
> With the Classpath implementation, this returns a result array with 
> values elements identical to the original array. (as expected, it just 
> does System.arraycopy). But with JDK6, the resulting elements are 
> slightly different. Same with CS_sRGB and toRGB().
>  
> Is it possible JDK6's color library is slightly innaccurate?

Actually, for performance reason (which is not the case in per-pixel 
conversions because of JNI overhead). JDK6 proprietary color management  
and littleCMS uses fixed point math.  JDK6 CM and littleCMS has 16 bit 
precision fixed point calculations (moreover littleCMS for some data 
formats uses 8-bit  fixed point math). So, because of that we have such 
a difference comparing with using exact formulas with double precision. 
LittleCMS has double precision codepaths but they are very slow, so 
cannot be used for image conversions (though might be useful for 
per-pixel stuff)

>
> Still, even if we take the JDK6 version as "accurate", the Classpath 
> version doesnt seem to be any less accurate than little cms (in fact, 
> from Romans test, it's actually closer on average) Still, to be sure 
> it would need to be tested with ICC profiles read from disc.
>  
> One last thing, if the java.awt.color was to be replaced with an 
> all-Java version, wouldnt the native graphics system depend on the 
> native color library?  I'd expect there'd be issues there.

Could you please clarify you question.

Best Regards,
Alexey

>
> ------------------------------------------------------------------------
> *From:* 2d-dev-bounces at openjdk.java.net on behalf of Roman Kennke
> *Sent:* Mon 14/05/2007 9:45 PM
> *To:* Jeannette.Hung at sun.com
> *Cc:* 2d-dev; Phil Race; Dmitri Trembovetski; Alexey Ushakov
> *Subject:* Re: DataBuffer, ColorModels and SampleModels
>
> Hi,
>
> > Wow...  That's a huge difference.  Did you compare the pixel values
> > between your build, the openjdk build, and the production JRE build?
>
> I did so just now. I bombed the standard jdk6 build with 1000000 random
> values and stored the conversion results in a file. Another program
> reads in those values and compares it with the same conversion on the
> current VM's build. Here are the results:
>
> plain OpenJDK:
> average difference from reference: 0.00380017
> maximum difference from reference: 0.038417127
>
> OpenJDK with Classpath CMS:
> average difference from reference: 0.00280433
> maximum difference from reference: 0.0042832294
>
> >   I
> > know the color code isn't straightforward for conversion between a gray
> > and a sRGB color space since I think the gray space is linear and the
> > sRGB one is not.
>
> Yeah right. And apparently the code needs more testing for other
> conversions than gray->rgb.
>
> /Roman
>
> --
> http://kennke.org/blog/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20070515/f547b758/attachment.html>