2/4 Support BigTIFF encoded TIFF data #584
Conversation
… than passing TIFF header offsets around everywhere.
Note that while BigTIFF supports files greater than 2 GiB in size, our current implementation does not due to the pervasive use of Int32 throughout the code to represent offsets into the data.
This will only ever be a 16-bit value.
This allows combining the add and test operations into a single lookup.
don-vip
changed the title
| final int tiffMarker = reader.getUInt16(2); | ||
| final short tiffMarker = (short) reader.getUInt16(2); |
There was a problem hiding this comment.
I'm not totally sure about this change, as Java doesn't have an unsigned short type (unlike .NET where this change is being ported from). Generally throughout the Java library we widen the type to allow the full unsigned range to remain unsigned. In this case though it's not really a numeric value used for any kind of size or comparison, but just an identifier. That said, it does change the public API, which is a breaking change. There are other breaking changes in these PRs though.
Just dumping out my thoughts here. I'm going to pull down your work here and take it for a spin before merging.
| * @return the 64 bit int value, between 0x0000000000000000 and 0xFFFFFFFFFFFFFFFF | ||
| * @throws IOException the buffer does not contain enough bytes to service the request, or index is negative | ||
| */ | ||
| public long getUInt64(int index) throws IOException |
There was a problem hiding this comment.
Java doesn't have an unsigned long, so this method is redundant as far as I can tell. Keeping it does at least allow calling code to express the intent, despite the limitation of the language.
I notice though that, comparing to getInt64 above, there are a bunch of && masks in that method that may be redundant (and possibly others too).
There was a problem hiding this comment.
you're right, I wasn't sure what to do. It mainly helps to compare the .NET and Java codebases.
| * @param handler the {@link com.drew.imaging.tiff.TiffHandler} that will coordinate processing and accept read values | ||
| * @param reader the {@link com.drew.lang.RandomAccessReader} from which the data should be read | ||
| * @param processedGlobalIfdOffsets the set of visited IFD offsets, to avoid revisiting the same IFD in an endless loop | ||
| * @param ifdOffset the offset within <code>reader</code> at which the IFD data starts | ||
| * @param isBigTiff >Whether the IFD uses the BigTIFF data format. |
There was a problem hiding this comment.
nit: there's a stray > character here.
| ? reader.getUInt64(finalTagOffset) | ||
| : reader.getUInt32(finalTagOffset); | ||
|
|
||
| if (nextIfdOffsetLong != 0 && nextIfdOffsetLong <= Integer.MAX_VALUE) { |
There was a problem hiding this comment.
The fact that getUInt64 might return a negative value is a problem here. I'm wondering if that method should be changed to throw if the value is actually negative. Otherwise we have to do things like check nextIfdOffsetLong < 0 here (and possibly elsewhere).
On the other hand, throwing might lead to failing to read data that would otherwise be safe to read.
I really wish Java had unsigned numeric types!
This is the second step towards solving #278
Port of these commits from drewnoakes/metadata-extractor-dotnet#302:
The PR is built on top of #581