Attempt to hold onto absolute position of a Directory relative to the original file/stream #36
Conversation
to the original file/stream. Allows Thumbnail Offset to be accurate.
|
I know it's been an age, but I recently started revisiting JPEG segment handling and I'll definitely get the spirit of this PR into the code somehow. Sorry again that it's taken so long to get to it. |
|
I've been rebasing this to address the merge conflicts and doing some review. In general we definitely stand to benefit from keeping track of some offsets during parsing. Adding Some directories don't really have a position:
Other directories potentially have multiple positions of interest, such as makernotes:
I agree that these values should be stored in properties on the directory classes themselves. But given the variations, modelling it (I'm still going through the changes, to ideas may vary in coming days. I'm capturing thoughts here as I go, as I only have short bursts of time to look at this now.) |
As per #35 and #36, the offsets were incorrectly constructed. Recent work on readers and JpegSegment formalises offsets a little more. Rather than storing the (potentially) large thumbnail bytes while extracting, a future implementation will allow extracting the thumbnail from the original data source in a second pass, probaly via ThumbnailDirectory.TryGetThumbnail(Stream)
As per #35 and #36, the offsets were incorrectly constructed. Recent work on readers and JpegSegment formalises offsets a little more. Rather than storing the (potentially) large thumbnail bytes while extracting, a future implementation will allow extracting the thumbnail from the original data source in a second pass, probaly via ThumbnailDirectory.TryGetThumbnail(Stream)
This is the long way around to try and address Issue #35. It introduces a "JpegSegment" object to pass around instead of a byte[] for segments. The object contains the byte[] previously sent, plus a starting position from when the segment was read relative to original file.
In one sense, it would have been easier to correct the thumbnail offset directly in ExifTiffHandler.Completed. However, as I was going through this it seemed like there might be use down the road for the original offset. One thing lead to another and a bunch of files were changed. This kind of demonstrates how complex it is to send this around the current readers/handlers, so I'll leave it up to you whether it's a "good" thing. It does fix the thumbnail issue, but at a cost. That said, it's a totally optional property and isn't used anywhere else. Also, not all file types were tested so this might be incomplete.