support reading up to two subifd's for tag 0x14a

[kwhopper]

One way to fix drewnoakes/metadata-extractor#103 reported on the Java version.

NEF puts one or more (usually one or two) subifd's in tag 0x014a as either an IFD or one or more longs. This push supports reading them as longs, and only the first two. I don't consider this a complete solution, but it gets it started and will only run when that tag exists.

Two new Directory classes were added to support this. Review that decision, although class explosion is a well known issue for subifd's anyway.

[drewnoakes]

Firstly, I'm quite surprised that ExifDirectoryBase.TagSubIfdOffset (0x014a) was completely unused by the lib!

Secondly, it's interesting to think that there could be more than one pointer.

Some preliminary research shows that this tag is used in IFD0 (by both Sony ARW and Leica DNG) and in the thumbnail IFD (by Samsung SRW). This brings up the issue that currently there's no way of differentiating which image this sub-IFD applies to. I'll have a think about modelling hierarchy in the returned directories so that consumers can differentiaate. I think the current ITiffHandler infrastructure should allow this easily enough.

[kwhopper]

This brings up the issue that currently there's no way of differentiating which image this sub-IFD applies to.

Yeah, I think this has/will become a bigger issue as more subifd's are added. The class "explosion" problem is one thing, but like in this case, some hierarchy will be needed. The part that wasn't kept in #37 (where it tried to register subifd's in an ifd) indirectly tried to do this. That wasn't the initial goal but now that I think about it, it sort of imperfectly did part of what you're describing. Maybe register other directories instead of tags? OTOH, this might be a new-version issue; it could change the library quite a bit.

[drewnoakes]

I think fcfb8d0 and aed57bc address the issue highlighted by this PR (excluding the hierarchy bit). You can see the significant impact it had on sample raw files in the image library here. Very cool!

Please review these changes if you have the chance.

[kwhopper]

I think that works. Line 220 of TiffReader could be less cryptic by just checking the component size (your math is effectively doing that anyway)...

if(format.ComponentSizeBytes == 4)

Good job! I'll go through some of the unknown tags that came from this; there weren't too many.

[drewnoakes]

I think it is possible (however unlikely) that 'format' is null (for
example if the type id is 13).

It'd be great to decode more of these unknown TIFF fields.

On Fri, 25 Mar 2016 13:25 kwhopper, [email protected] wrote:

I think that works. Line 220 of TiffReader could be less cryptic by just
checking the component size (your math is effectively doing that anyway)...

if(format.ComponentSizeBytes == 4)

Good job! I'll go through some of the unknown tags that came from this;
there weren't too many.

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#42 (comment)

[drewnoakes]

This has been ported to Java too now. Closing this. Reopen if you feel it's needed.