Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TIFF tag 41728 inconsistency #767

Closed
thorsted opened this issue Jun 27, 2022 · 1 comment · Fixed by #804
Closed

TIFF tag 41728 inconsistency #767

thorsted opened this issue Jun 27, 2022 · 1 comment · Fixed by #804
Assignees
Labels
bug A product defect that needs fixing P3 Low priority bugs
Milestone

Comments

@thorsted
Copy link

The TIFF tag 41728 (Filesource) is not extracted properly. In the GUI the "Filesource" line is visible but no value. In XML output, tag is skipped entirely.
Screen Shot 2022-06-27 at 4 30 37 PM

Attached is three examples of this tag used in a TIFF.
FileSource-Samples.zip

First is the tag used in Exif properly (test01-ExifIFD.tif)
Another is a custom tag with no Exif (test01-IFD0.tif) used by LOC NDNP
Another is the custom tag converted to Exif with maintaining string instead of numerical value (test01-IFD0v2.tif)

Custom tag is ignore by MD extraction, but when used properly in Exif value is not extracted by JHOVE.

@carlwilson carlwilson self-assigned this Jul 7, 2022
@carlwilson carlwilson added bug A product defect that needs fixing P3 Low priority bugs labels Jul 7, 2022
@carlwilson carlwilson added this to the JHOVE 1.28 milestone Jul 7, 2022
@tledoux
Copy link
Contributor

tledoux commented Dec 11, 2022

The proposed PR will allow he first file to be handled properly in all the outputs (indeed, having no description for the values 1 and 2, implies an empty output in text and no tags to be output for XML).

For the 2nd file, you get an message TIFF-HUL-12 stating correctly that the tag TIFF IFD 41728 is unknown, since it should be in an EXIF IFD.

For the third file, the TIFF-HUL is very unforgiving. Indeed, the EXIF IFD 41728 has a ASCII (2) type where the UNDEFINED (7) type is expected for this IFD as required by the Exif standard. Note also that the length of the IFD is supposed to be 1 byte...

Here we hit a questionnable behaviour of the TIF-hul that stops processing as soon as a "bad" use of a type is encountered. The behaviour shoud probably be more lax, but it's currently the case...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A product defect that needs fixing P3 Low priority bugs
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants