[
https://issues.apache.org/jira/browse/IMAGING-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17197298#comment-17197298
]
Gary Lucas edited comment on IMAGING-265 at 9/18/20, 12:29 PM:
---------------------------------------------------------------
It took a while, but I've identified the problem and I think that the original
authors of TIFF were in love with complexity.
It turns out that there is a specification in the TIFF standard on how a file
may store the RGB components in a file. The arrangement is specified using a
TIFF tag known as Planar Configuration and there are two variations:
You may specify them in a sequence of bytes such as
R1, G1, B1, R2, G2, B2, R3, G3, B3, ... , Rn, Gn, Bn (Planar Configuration 1)
But you can also split the data into separate "planes" such as
R1, R1, R2,... Rn, G1, G2, G3,...Gn, B1, B2, B3, ... Bn. (Planar Configuration
2)
The problematic image uses Planar Configuration 2. Searching through the code,
I don't find any evidence of Planar Configuration 2 implemented anywhere. So it
looks like this configuration is not currently supported by Commons Imaging.
The array bounds failure occurs because the small_world.tif file is organized
into blocks of 8000 bytes representing strips of 20 rows 400 pixels wide. In
Planar Configuration 1, the code would expect to see 3 bytes per pixel, or
24000 bytes per strip (block). In Planar Configuration 2, the data is split
between 3 blocks of 8000 which have to be combined to get a full set of RGB
values. Since Commons Imaging does not recognize Planar Configuration 2 (at
least, not yet), it thinks it has 24000 bytes to process and wackiness ensues.
THE USUAL PLEA FOR TEST DATA
I have a fix in mind that will address this particular file. But it will only
work for files using the RGB color model and organized into strips with no data
compression. I could easily extend it for files organized with tiles, but I
have no test data. And that still leaves the issue of different photometric
interpreters and data compression. I'm not sure that these options even matter,
because I suspect that Planar Configuration 2 is unusual in modern data systems.
For the OpenJUMP folks: As a temporary work-around, you can try to use
interleaved RGB rather than the separate planes. I know that's not much of a
help if you're not in control of the format for the images you receive, but at
least you will know why some images don't work.
And finally, just as a point of interest, I've attached a JPEG showing the
3-plane content of the small world file. I hacked Commons Imaging so that it
wouldn't crash when I read the file. But, clearly, I have more work to do to
render it properly.
!small_world_split.jpg!
was (Author: gwlucas):
It took a while, but I've identified the problem and I think that the original
authors of TIFF were in love with complexity.
It turns out that there is a specification in the TIFF standard on how a file
may store the RGB components in a file. The arrangement is specified using a
TIFF tag known as Planar Configuration and there are two variations:
You may specify them in a sequence of bytes such as
R1, G1, B1, R2, G2, B2, R3, G3, B3, ... , Rn, Gn, Bn (Planar
Configuration 1)
But you can also split the data into separate "planes" such as
R1, R1, R2,... Rn, G1, G2, G3,...Gn, B1, B2, B3, ... Bn. (Planar
Configuration 2)
The problematic image uses Planar Configuration 2. Searching through the code,
I don't find any evidence of Planar Configuration 2 implemented anywhere. So
it looks like this configuration is not currently supported by Commons Imaging.
The array bounds failure occurs because the small_world.tif file is organized
into blocks of 8000 bytes representing strips of 20 rows 400 pixels wide. In
Planar Configuration 1, the code would expect to see 3 bytes per pixel, or
24000 bytes per strip (block). In Planar Configuration 2, the data is split
between 3 blocks of 8000 which have to be combined to get a full set of RGB
values. Since Commons Imaging does not recognize Planar Configuration 2 (at
least, not yet), it thinks it has 24000 bytes to process and wackiness ensues.
THE USUAL PLEA FOR TEST DATA
I have a fix in mind that will address this particular file. But it will only
work for files using the RGB color model and organized into strips with no data
compression. I could easily extend it for files organized with tiles, but I
have no test data. And that still leaves the issue of different photometric
interpreters and data compression. I'm not sure that these options even matter,
because I suspect that Planar Configuration 2 is unusual in modern data systems.
For the OpenJUMP folks: As a temporary work-around, you can try to use
interleaved RGB rather than the separate planes. I know that's not much of a
help if you're not in control of the format for the images you receive, but at
least you will know what some images don't work.
And finally, just as a point of interest, I've attached a JPEG showing the
3-plane content of the small world file. I hacked Commons Imaging so that it
wouldn't crash when I read the file. But, clearly, I have more work to do to
render it properly.
!small_world_split.jpg!
> ArrayIndexOutOfBoundsException on reading simple GeoTIFF
> --------------------------------------------------------
>
> Key: IMAGING-265
> URL: https://issues.apache.org/jira/browse/IMAGING-265
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
> Affects Versions: 1.0-alpha2
> Reporter: edgar soldin
> Priority: Major
> Attachments: small_world.tif, small_world_split.jpg
>
>
> hi,
>
> we on the OpenJUMP project cannot open some GeoTIFFs with commons.imaging .
> for details you may find a ticket in our bug tracker
> [https://sourceforge.net/p/jump-pilot/bugs/498/] .
>
> the gist is: on loading the attached file getBufferedImage() fails with this
> stack
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 8000Caused by:
> java.lang.ArrayIndexOutOfBoundsException: 8000 at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.interpretStrip(DataReaderStrips.java:196)
> at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:665)
> at
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:469)
> at org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1442) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1335) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1304) at
> com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:108)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
