DataBuffer, ColorModels and SampleModels

[LOUD, Ben]

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? 

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.

________________________________

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/3e92a4b8/attachment.html>