[
https://issues.apache.org/jira/browse/IMAGING-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762356#comment-17762356
]
Gary Lucas commented on IMAGING-316:
------------------------------------
I requested and received permission from Joris Van Damme (of AWare Systems) to
include the sample BigTIFF files I mentioned in the Commons Imaging
distribution under the test resources files. These samples are a set of 8
BigTIFF files and one conventional TIFF file provided for reference purposes.
The files are relatively small, making the whole collection come in at 158 KB
(the "big" refers to the 64-bit address space, not the actual size of the
files). This collection exercises all of the core functions that are affected
by the 64-bit address space and will provide a solid basis for JUnit tests.
I will, of course, include a proper citation and grateful acknowledgement of
the data source in a README.TXT file.
To learn more about BigTIFF, visit Mr. Van Damme's page at
[https://www.awaresystems.be/imaging/tiff/bigtiff.html]
> 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)
