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 D. Gregory (Jira)" <ji...@apache.org> on 2023/09/30 15:20:00 UTC

[jira] [Resolved] (IMAGING-316) Support the BigTIFF file format

     [ https://issues.apache.org/jira/browse/IMAGING-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary D. Gregory resolved IMAGING-316.
-------------------------------------
    Fix Version/s: 1.0
       Resolution: Fixed

> Support the BigTIFF file format
> -------------------------------
>
>                 Key: IMAGING-316
>                 URL: https://issues.apache.org/jira/browse/IMAGING-316
>             Project: Commons Imaging
>          Issue Type: New Feature
>    Affects Versions: 1.x
>            Reporter: Gary Lucas
>            Priority: Major
>             Fix For: 1.0
>
>
> Traditional TIFF files address file position in bytes using 32-bit integers.  This approach automatically limits the maximum size of a TIFF file to 4 GB.  The BigTIFF specification (formalized in 2011) uses 64-bit integers to address file positions, and thus supports much larger files.  I propose that a future release of Commons Imaging would benefit from supporting BigTIFF.
> The level of effort for this implementation may be large. 
> In terms of creating JUnit tests to support this effort, note that just because a file uses the BigTIFF specification doesn't mean that the file has to be super large. It should be possible to create BigTIFF test files that are only a few kilobytes.  Thus supporting BigTIFF does not necessarily mean that massive files will need to be included in the Commons Imaging distribution.
> Finally, it is reasonable to ask if anyone would actually need images that were so large that they couldn't fit within 4 GB.   The short answer is that some folks in the Geographic Information Systems (GIS) community do work with images (or data sets) that large and, also, that some systems produce images in BigTIFF format even when ordinary TIFF would suffice.
>  
> P.S. It might be work investigating whether the existing Imaging library actually supports the full 32-bit address space of a conventional TIFF.  Regrettably,  Java doesn't support unsigned integer types.  And it is possible that a file address with the high bit set might be incorrectly interpreted as a negative number.  So I will be taking a look at the code to make sure all file addresses are properly masked when they are handed over to Java.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)