[
https://issues.apache.org/jira/browse/PDFBOX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026905#comment-14026905
]
John Hewson commented on PDFBOX-2117:
-------------------------------------
{quote}
It seems to me that PDDeviceRGB#toRGBImage() does not do any conversion, it
just creates a buffered image with sRGB color space and the unchanged original
data. Would not it be consistent to return the unchanged original value from
PDDeviceRGB#toRGB() as well? However, when I debug it, the #toRGB() returns
slightly modified values - which I do not understand since the java doc in
java.awt.color.ColorSpace#toRGB() tells that it converts values in "this" color
space into sRGB. If "this color space is sRGB, why should the returned values
be different?
{quote}
PDFBox has always used Java's sRGB color space to do this conversion, I'm not
sure what the reasoning behind that is. What you're seeing may be the
difference between linear RGB and sRGB, though I can't say what the correct
result should be. "DeviceRGB" is ultimately the decision of the device.
I'm surprised that toRGBImage() is not faster, we saw CMYK images going from
taking 60sec with toRGB to taking 4 sec with toRGBImage(). In your patch you
can just return rgbImage.getRaster() because getColorModel() always returns
sRGB.
> AxialShadingContext is slow
> ---------------------------
>
> Key: PDFBOX-2117
> URL: https://issues.apache.org/jira/browse/PDFBOX-2117
> Project: PDFBox
> Issue Type: Improvement
> Reporter: Petr Slaby
> Attachments: 000001_MTEXT_CS6.pdf, AxialShading.patch,
> AxialShading1.patch, AxialShadingContext.java.getrgbimage,
> Shading2Function2text.pdf, asy-shade.pdf, color_gradient.pdf,
> shading_pattern.pdf
>
>
> AxialShadingContext#getRaster() is on top of profiler hot spots in documents
> that use an axial shading. Inside it, the slowest part is calling
> PDColorSpaceRGB#toRGB() and PDFunctionType3#eval() (in this order).
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
