2/4 Support BigTIFF encoded TIFF data #584
Conversation
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.
| ? 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!
… 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.
|
This one looks good too, I see the Java <> .NET differences disappear for BigTIFF files |
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