[
https://issues.apache.org/jira/browse/PDFBOX-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hewson updated PDFBOX-1893:
--------------------------------
Description:
I'm currently working on this, so I wanted to open an issue to let everyone
know.
Color spaces need to be refactored in 2.0.0. Tilman noticed slowness in
PDFBOX-1851 due to using ICC profiles and calling ColorSpace#toRGB for every
pixel. For example, the file from PDFBOX-1851 went from rendering in 4 seconds
to taking over 60 seconds.
The solution is to use ColorConvertOp to convert an entire BufferedImage in one
go, taking advantage of AWT's native color management module. Color conversions
done this way are almost instantaneous, even for large images.
The current design of color spaces within PDFBox depends upon conversions being
done on a per-pixel basis, so a significant refactoring is needed in order to
convert images using ColorConvertOp without having to resort to per-pixel calls
in cases such as a Separation color space which uses a CMYK alternate color
space via a tint-transform.
The color space handling code is also tightly coupled to image handling. The
various classes which read images each have their own color handling code which
rely on per-pixel conversions. For this reason any color space refactoring must
also included a significant refactoring of image handling code. This is an
opportunity to refactor all color handling so that it is encapsulated within
the color space classes, allowing downstream users to call toRGB(float[]) or
toRGB(BufferedImage) and not need to worry about tint transforms and the like.
was:
I'm currently working on this, so I wanted to open an issue to let everyone
know.
Color spaces need to be refactored in 2.0.0. Tilman noticed slowness in
PDFBOX-1851 due to using ICC profiles and calling {{ColorSpace#toRGB}} for
every pixel. For example, the file from PDFBOX-1851 went from rendering in 4
seconds to taking over 60 seconds.
The solution is to use {{ColorConvertOp}} to convert an entire
{{BufferedImage}} in one go, taking advantage of AWT's native color management
module. Color conversions done this way are almost instantaneous, even for
large images.
The current design of color spaces within PDFBox depends upon conversions being
done on a per-pixel basis, so a significant refactoring is needed in order to
convert images using {{ColorConvertOp}} without having to resort to per-pixel
calls in cases such as a Separation color space which uses a CMYK alternate
color space via a tint-transform.
The color space handling code is also tightly coupled to image handling. The
various classes which read images each have their own color handling code which
rely on per-pixel conversions. For this reason any color space refactoring must
also included a significant refactoring of image handling code. This is an
opportunity to refactor all color handling so that it is encapsulated within
the color space classes, allowing downstream users to call {{toRGB(float[])}}
or {{toRGB(BufferedImage)}} and not need to worry about tint transforms and the
like.
> Refactor color spaces
> ---------------------
>
> Key: PDFBOX-1893
> URL: https://issues.apache.org/jira/browse/PDFBOX-1893
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel, Utilities
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
> Labels: color
>
> I'm currently working on this, so I wanted to open an issue to let everyone
> know.
> Color spaces need to be refactored in 2.0.0. Tilman noticed slowness in
> PDFBOX-1851 due to using ICC profiles and calling ColorSpace#toRGB for every
> pixel. For example, the file from PDFBOX-1851 went from rendering in 4
> seconds to taking over 60 seconds.
> The solution is to use ColorConvertOp to convert an entire BufferedImage in
> one go, taking advantage of AWT's native color management module. Color
> conversions done this way are almost instantaneous, even for large images.
> The current design of color spaces within PDFBox depends upon conversions
> being done on a per-pixel basis, so a significant refactoring is needed in
> order to convert images using ColorConvertOp without having to resort to
> per-pixel calls in cases such as a Separation color space which uses a CMYK
> alternate color space via a tint-transform.
> The color space handling code is also tightly coupled to image handling. The
> various classes which read images each have their own color handling code
> which rely on per-pixel conversions. For this reason any color space
> refactoring must also included a significant refactoring of image handling
> code. This is an opportunity to refactor all color handling so that it is
> encapsulated within the color space classes, allowing downstream users to
> call toRGB(float[]) or toRGB(BufferedImage) and not need to worry about tint
> transforms and the like.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
