You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gary Lucas (JIRA)" <ji...@apache.org> on 2012/05/06 22:17:48 UTC
[jira] [Created] (SANSELAN-80) Incorrect code for tiled TIFF files
applyPredictor method
Gary Lucas created SANSELAN-80:
----------------------------------
Summary: Incorrect code for tiled TIFF files applyPredictor method
Key: SANSELAN-80
URL: https://issues.apache.org/jira/browse/SANSELAN-80
Project: Commons Sanselan
Issue Type: Bug
Components: Format: TIFF
Reporter: Gary Lucas
Priority: Minor
I believe that the DataReaderTiled class used for reading tiled TIFF files invokes the applyPredictor method with incorrect arguments and will not be able to properly decode TIFF files that use predictors. The bug was found during a code inspection. Unfortunately, I do not have any samples of data in this format (there are none in the Apache Imaging test files) and cannot verify that this is the case.
Some Background
TIFF files are often used to store images in technical applications where data must be faithfully preserved, so lossy compression methods like JPEG are inappropriate and non-lossy method like LZW must be used. However, continuous tone images like satellite images or photographs often do not compress well since there is little apparent redundancy in the data. To improve the redundancy of the data, TIFF uses a simple predictor. The first pixel (gray tone or RGB value) in a tile is stored as a literal value. All subsequent pixels are stored as differences. To see how this works, imagine a monochrome picture where the gray tones gradually fade from white to black at a steady rate. Although no particular data value is ever repeated (so there is little apparent redundancy in the source data) the delta values remain constant (so a set of delta values will compress very well). When transformed in this matter, certain images show substantial improvements in compression ratio.
The Probem
The DataReaderTiff class uses a method called applyPredictor that takes an argument telling it whether the sample passed in is the first value, and should be treated as a literal, or whether it is a subsequent value and should be treated as a delta. Unfortunately, the parameter it uses is the x coordinate of the pixel to be decoded. While this approach works for TIFF strip files (where the first pixel always has a coordinate of zero), it does not work for tiles where the first pixel in the tile could fall anywhere in the image.
The Fix
While we could simply fix the argument passed into the predictor, there is a better solution. The predictor performs an if/then operation on the input parameter to find out if it is the first sample in the tile. Once it unpacks a sample, it retains it as the "last" value so that it may be added to the next delta value. Why not simply get rid of the if/then operation and just ensure that the last value gets zeroed out before beginning the processing of a strip or tile. This would save an if/then operation and fix the bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IMAGING-33) Incorrect code for tiled TIFF files
applyPredictor method
Posted by "Damjan Jovanovic (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IMAGING-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Damjan Jovanovic resolved IMAGING-33.
-------------------------------------
Resolution: Fixed
Fix Version/s: 1.0
Thank you for your bug report.
Patch and test images committed to SVN, resolving fixed.
> Incorrect code for tiled TIFF files applyPredictor method
> ----------------------------------------------------------
>
> Key: IMAGING-33
> URL: https://issues.apache.org/jira/browse/IMAGING-33
> Project: Apache Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
> Reporter: Gary Lucas
> Priority: Minor
> Fix For: 1.0
>
>
> I believe that the DataReaderTiled class used for reading tiled TIFF files invokes the applyPredictor method with incorrect arguments and will not be able to properly decode TIFF files that use predictors. The bug was found during a code inspection. Unfortunately, I do not have any samples of data in this format (there are none in the Apache Imaging test files) and cannot verify that this is the case.
> Some Background
> TIFF files are often used to store images in technical applications where data must be faithfully preserved, so lossy compression methods like JPEG are inappropriate and non-lossy method like LZW must be used. However, continuous tone images like satellite images or photographs often do not compress well since there is little apparent redundancy in the data. To improve the redundancy of the data, TIFF uses a simple predictor. The first pixel (gray tone or RGB value) in a tile is stored as a literal value. All subsequent pixels are stored as differences. To see how this works, imagine a monochrome picture where the gray tones gradually fade from white to black at a steady rate. Although no particular data value is ever repeated (so there is little apparent redundancy in the source data) the delta values remain constant (so a set of delta values will compress very well). When transformed in this matter, certain images show substantial improvements in compression ratio.
> The Probem
> The DataReaderTiff class uses a method called applyPredictor that takes an argument telling it whether the sample passed in is the first value, and should be treated as a literal, or whether it is a subsequent value and should be treated as a delta. Unfortunately, the parameter it uses is the x coordinate of the pixel to be decoded. While this approach works for TIFF strip files (where the first pixel always has a coordinate of zero), it does not work for tiles where the first pixel in the tile could fall anywhere in the image.
>
> The Fix
> While we could simply fix the argument passed into the predictor, there is a better solution. The predictor performs an if/then operation on the input parameter to find out if it is the first sample in the tile. Once it unpacks a sample, it retains it as the "last" value so that it may be added to the next delta value. Why not simply get rid of the if/then operation and just ensure that the last value gets zeroed out before beginning the processing of a strip or tile. This would save an if/then operation and fix the bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IMAGING-33) Incorrect code for tiled TIFF files
applyPredictor method
Posted by "Damjan Jovanovic (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IMAGING-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271140#comment-13271140 ]
Damjan Jovanovic commented on IMAGING-33:
-----------------------------------------
You can use:
tiffcp -t -c lzw:2 in.tif out.tif
to generate a suitable tiled predicted image.
> Incorrect code for tiled TIFF files applyPredictor method
> ----------------------------------------------------------
>
> Key: IMAGING-33
> URL: https://issues.apache.org/jira/browse/IMAGING-33
> Project: Apache Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
> Reporter: Gary Lucas
> Priority: Minor
>
> I believe that the DataReaderTiled class used for reading tiled TIFF files invokes the applyPredictor method with incorrect arguments and will not be able to properly decode TIFF files that use predictors. The bug was found during a code inspection. Unfortunately, I do not have any samples of data in this format (there are none in the Apache Imaging test files) and cannot verify that this is the case.
> Some Background
> TIFF files are often used to store images in technical applications where data must be faithfully preserved, so lossy compression methods like JPEG are inappropriate and non-lossy method like LZW must be used. However, continuous tone images like satellite images or photographs often do not compress well since there is little apparent redundancy in the data. To improve the redundancy of the data, TIFF uses a simple predictor. The first pixel (gray tone or RGB value) in a tile is stored as a literal value. All subsequent pixels are stored as differences. To see how this works, imagine a monochrome picture where the gray tones gradually fade from white to black at a steady rate. Although no particular data value is ever repeated (so there is little apparent redundancy in the source data) the delta values remain constant (so a set of delta values will compress very well). When transformed in this matter, certain images show substantial improvements in compression ratio.
> The Probem
> The DataReaderTiff class uses a method called applyPredictor that takes an argument telling it whether the sample passed in is the first value, and should be treated as a literal, or whether it is a subsequent value and should be treated as a delta. Unfortunately, the parameter it uses is the x coordinate of the pixel to be decoded. While this approach works for TIFF strip files (where the first pixel always has a coordinate of zero), it does not work for tiles where the first pixel in the tile could fall anywhere in the image.
>
> The Fix
> While we could simply fix the argument passed into the predictor, there is a better solution. The predictor performs an if/then operation on the input parameter to find out if it is the first sample in the tile. Once it unpacks a sample, it retains it as the "last" value so that it may be added to the next delta value. Why not simply get rid of the if/then operation and just ensure that the last value gets zeroed out before beginning the processing of a strip or tile. This would save an if/then operation and fix the bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IMAGING-33) Incorrect code for tiled TIFF files
applyPredictor method
Posted by "Gary Lucas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IMAGING-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271490#comment-13271490 ]
Gary Lucas commented on IMAGING-33:
-----------------------------------
Thanks. Nice job on the changes, they're exactly what I had in mind... Now the code is both more correct than it was before and also a little bit faster as well.
> Incorrect code for tiled TIFF files applyPredictor method
> ----------------------------------------------------------
>
> Key: IMAGING-33
> URL: https://issues.apache.org/jira/browse/IMAGING-33
> Project: Apache Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
> Reporter: Gary Lucas
> Priority: Minor
> Fix For: 1.0
>
>
> I believe that the DataReaderTiled class used for reading tiled TIFF files invokes the applyPredictor method with incorrect arguments and will not be able to properly decode TIFF files that use predictors. The bug was found during a code inspection. Unfortunately, I do not have any samples of data in this format (there are none in the Apache Imaging test files) and cannot verify that this is the case.
> Some Background
> TIFF files are often used to store images in technical applications where data must be faithfully preserved, so lossy compression methods like JPEG are inappropriate and non-lossy method like LZW must be used. However, continuous tone images like satellite images or photographs often do not compress well since there is little apparent redundancy in the data. To improve the redundancy of the data, TIFF uses a simple predictor. The first pixel (gray tone or RGB value) in a tile is stored as a literal value. All subsequent pixels are stored as differences. To see how this works, imagine a monochrome picture where the gray tones gradually fade from white to black at a steady rate. Although no particular data value is ever repeated (so there is little apparent redundancy in the source data) the delta values remain constant (so a set of delta values will compress very well). When transformed in this matter, certain images show substantial improvements in compression ratio.
> The Probem
> The DataReaderTiff class uses a method called applyPredictor that takes an argument telling it whether the sample passed in is the first value, and should be treated as a literal, or whether it is a subsequent value and should be treated as a delta. Unfortunately, the parameter it uses is the x coordinate of the pixel to be decoded. While this approach works for TIFF strip files (where the first pixel always has a coordinate of zero), it does not work for tiles where the first pixel in the tile could fall anywhere in the image.
>
> The Fix
> While we could simply fix the argument passed into the predictor, there is a better solution. The predictor performs an if/then operation on the input parameter to find out if it is the first sample in the tile. Once it unpacks a sample, it retains it as the "last" value so that it may be added to the next delta value. Why not simply get rid of the if/then operation and just ensure that the last value gets zeroed out before beginning the processing of a strip or tile. This would save an if/then operation and fix the bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira