[ 
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

        

Reply via email to