[ome-users] Invalid values stored in TIFF-tag 'StripByteCounts' when writing striped OME-TIFF

[Curtis Rueden]

Hi Roger & everyone,


> This logic was added to getStripByteCounts() in commit 0599079, but for
> all compressed formats, and was switched to LZW-only as above in
> bf1dcbe9.  I'm not sure what makes LZW special here compared with the
> other compression formats.


Actually, the change from "!= UNCOMPRESSED" to "== LZW" was made in commit
df21380b:

The commit message is:
"Only double StripByteCounts values if the strips are compressed with LZW.
 Fixes #368."

That bug can be viewed here:
http://dev.loci.wisc.edu/trac/software/ticket/368

HTH,
Curtis


On Mon, Sep 10, 2012 at 7:03 AM, Roger Leigh <r.leigh at dundee.ac.uk> wrote:

> On 07/09/2012 16:31, Matthias Baldauf wrote:
>
>> I am using the Bio-Formats Java library (trunk build) to write an
>> OME-TIFF sequentially strip per strip.
>> It is basically the same approach I mentioned in a previous post
>> (http://lists.openmicroscopy.**org.uk/pipermail/ome-users/**
>> 2012-August/003178.html<http://lists.openmicroscopy.org.uk/pipermail/ome-users/2012-August/003178.html>
>> ),
>> but now I am reading the JPEG in stripes and store them strip per strip
>> in an OME-TIFF. It works great for striped uncompressed OME-TIFFs.
>>
>> However, when using LZW compression, it nearly ever results in an
>> OME-TIFF which cannot be opened.
>> To locate the error I analyzed the IFD of the TIFF and observed that the
>> tag 'StripByteCounts' doesn’t contain valid values.
>>
>> In the case when there are just a few stripes in the OME-TIFF, the
>> values of 'StripByteCounts' are too large, even exceeding the number of
>> bytes when the strip would be uncompressed.
>> In the case when there are more stripes in the OME-TIFF, the values of
>> 'StripByteCounts' are zero.
>> So I had a look at the IFD-class in the loci.formats.tiff package an
>> encountered the following lines in the getStripByteCounts() method:
>>
>>      if (getCompression() == TiffCompression.LZW) {
>>        for (int i=0; i<byteCounts.length; i++) {
>>          counts[i] = byteCounts[i] * 2;
>>        }
>>      }
>>
>> I removed the multiplication (* 2) and it seems to solve the error with
>> the wrong values of 'StripByteCounts'.
>> The OME-TIFFs can be opened now (even containing many stripes).
>> The multiplication increases the values of 'StripByteCounts' every time
>> a strip gets stored in the OME-TIFF.
>> This would explain the very large numbers and, when more strips are
>> added, the zeros because of an overflow.
>>
>
> Just to add a small additional bit of data:
>
> This logic was added to getStripByteCounts() in commit 0599079, but for
> all compressed formats, and was switched to LZW-only as above in
> bf1dcbe9.  I'm not sure what makes LZW special here compared with the
> other compression formats.
>
>
> Regards,
> Roger
>
> --
> Dr Roger Leigh -- Open Microscopy Environment
> Wellcome Trust Centre for Gene Regulation and Expression,
> College of Life Sciences, University of Dundee, Dow Street,
> Dundee DD1 5EH Scotland UK   Tel: (01382) 386364
>
> The University of Dundee is a registered Scottish Charity, No: SC015096
>
> ______________________________**_________________
> ome-users mailing list
> ome-users at lists.**openmicroscopy.org.uk<ome-users at lists.openmicroscopy.org.uk>
> http://lists.openmicroscopy.**org.uk/mailman/listinfo/ome-**users<http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-users/attachments/20120910/03541116/attachment.html>