[ https://issues.apache.org/jira/browse/IMAGING-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763473#comment-17763473 ]
Gary Lucas commented on IMAGING-316: ------------------------------------ Have an updated version of the Commons Imaging library that successfully reads all of the sample images at the AWare Systems website. Am working on the JUnits tests. I expect to submit a pull request in the next few days. > 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)