[
https://issues.apache.org/jira/browse/IMAGING-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762228#comment-17762228
]
Gary Lucas commented on IMAGING-316:
------------------------------------
I've located a great page with resources for the BigTIFF file format.
AWare Systems has posted a page on the [The BigTIFF File
format|https://www.awaresystems.be/imaging/tiff/bigtiff.html] that describes
the enhancements required to support BigTIFF and provides a comprehensive set
of test tiles to exercise any API that reads BigTIFF. These resources will be
a great boost in developing this feature for Commons Imaging.
> 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
>
> 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)
