[
https://issues.apache.org/jira/browse/PDFBOX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020990#comment-14020990
]
Petr Slaby commented on PDFBOX-2117:
------------------------------------
John, just for my understanding. 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?
I did not manage to rewrite the AxialShadingData in the free twenty minutes I
had now, it will have to take into account that the number of raster bands
depends on shading color model. So I cannot tell what is the effect of using
toRGBImage() instead of toRGB(). Maybe I shall leave it now for the student
with the discussion in this issue being at least some input for her?
> AxialShadingContext is slow
> ---------------------------
>
> Key: PDFBOX-2117
> URL: https://issues.apache.org/jira/browse/PDFBOX-2117
> Project: PDFBox
> Issue Type: Improvement
> Reporter: Petr Slaby
> Attachments: AxialShading.patch, AxialShading1.patch,
> 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)
