Vincent Hennebert created BATIK-1081:
----------------------------------------

             Summary: "Unable to transform src image" error when running 
regard.samplesRendering.samples.samples/batik70.svg on JRE 1.6 and above
                 Key: BATIK-1081
                 URL: https://issues.apache.org/jira/browse/BATIK-1081
             Project: Batik
          Issue Type: Bug
          Components: SVG Rasterizer
            Reporter: Vincent Hennebert


In o.a.b.ext.awt.image.rendered.AffineRed.genRect, a call is made to 
AffineTransformOp.filter. That throws an ImagingOpException("Unable to 
transform src image") on the batik70.svg input.

The failure comes from the awt_parseColorModel function in 
src/jdk/src/share/native/sun/awt/image/awt_parseImage.c. It fails on line 514 
in the test {{if (cmP->csType != java_awt_color_ColorSpace_TYPE_RGB || 
!cmP->is_sRGB)}}. The color space is of type RGB but {{is_sRGB}} is false. So 
the code decides it cannot handle it.

The color model is not sRGB because, earlier in Batik, a call to 
o.a.b.ext.awt.image.rendered.Any2LsRGBRed.fixColorModel is made, that returns 
either GraphicsUtil.Linear_sRGB_Unpre or GraphicsUtil.Linear_sRGB. And despite 
their names, those color models use ColorSpace.CS_LINEAR_RGB which is different 
to ColorSpace.CS_sRGB.

That is why the boolean is_sRGB mentioned above is kept to false, and the 
native code refuses to handle it.

It used to be working with a 1.5 JRE. It doesn't work with OpenJDK 1.6, 1.7 and 
Oracle 1.8. I assume that on earlier JREs the code was less strict, possibly 
behaving wrongly in some cases.

The exception goes if in the definition of GraphicsUtil.Linear_sRGB et al, the 
CS_LINEAR_RGB color space is replaced with CS_sRGB. The image is then rendered 
fine.

However, that causes regressions in other test cases (one of them being 
regard.samplesRendering.samples.samples/batikBatik.svg), that otherwise pass. 
Colors become quite different to the original.

Whether using CS_LINEAR_RGB is correct or not is hard to tell. All the SVG 
viewers I've tried give different results. Firefox and Squiggle do tend to have 
similar colors, which leads me to think that they are correct. That said, the 
SVG Recommendation does state that SVG colors should be in the sRGB color space 
by default.

Leaving the code as is will make Batik fail on some inputs if run with a 1.6+ 
JRE. Changing the code will cause some inputs to render differently.

I guess we rather want to be conservative and leave things as is until we have 
a chance to further investigate the issue. Users who are facing the failure 
have the option to revert to an older JRE. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-h...@xmlgraphics.apache.org

Reply via email to