Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
description : The value of TIFFOffset is not approciate and setting D… #381
Hi @jaehojung, thanks for your patch. I see that you have created a bug report on redmine: http://dev.exiv2.org/issues/1359. Could you please provide us with a test image that fails when being processed by exiv2, before applying your patch? You can drag-and-drop the image here, I'll then be able to take a look at the issue more closely.
That file is definitely corrupted, I cannot open it with any image viewer. What happened to it?
Exiv2 build from master cannot find anything in that file, but with your patch it at least finds the resolution (like exiftool does). I'll have to take a look at the tiff file specifications to be able to decide whether we want to merge this (that might take a while).
@clanmills The test file can be found here: https://user-images.githubusercontent.com/18898538/42606059-50399768-85b6-11e8-9acd-bad8e8690afb.jpg. It's linked in the third comment.
If I understand this patch correctly it just works around a wrong header offset. However, I can't really asses what it causes further in the parser.
@clanmills The test file is in the third command, you can right-click and save it under a different name.
This is very interesting. I've updated Redmine #1359 appropriately including the test file.
Thank You for the test file. I downloaded that earlier and was confused when it was a JPEG. Because the subject involves tiff, I was expecting a tiff file.
I've investigated your file and can extract some metadata.
Here's a document I made about the structure of Tiff files:
It's clear that the Exif/APP1 block is malformed. Let's extract that:
The offset record 0x470e is incorrect. I've modified it with HexFiend to be 8
And now I can see metadata:
Ah, something interesting. For sure the dates smell OK. The lens looks plausable.
Your patch does not implement my manual edit. I will have to further correct the TIFF directory chain to avoid the error
The output of exiftool is suspicious and contains no Exif data (warning: Bad IFD0 directory).
There's something wrong with the IPTC data block of 502 bytes. In addition to have NUL data, the copyright length is 10524 bytes. Thats impossible and will almost certainly cause security issues in some applications.
Before we can make progress with this, you'll have to convince me that there is a "business case" for working on this. The file is clearly seriously malformed and cannot be opened in image processing applications. What is the origin of this file? For example: camera or a desktop application?
You're going to find it difficult to persuade me that we should support this file. Saying that exiftool operates on this file is not a strong argument as it clearly does not read the Exif metadata.
I've studied your file and documented my analysis. I have proven that neither exiftool nor exiv2 reads the Exif metadata embedded in your file.
I think you've misunderstood my request for a 'business case'. I don't need to know about your private aims, however I need to know why Exiv2 should read metadata from a file which violates the standard.
A convincing 'business case' would be to something substantial such as:
The patch you provided is not correct. You are correct to realise that the offset() is wrong, however the correct value is
My suggestion to you is to write a small utility program "fixjpeg" which would open a JPEG and carry out the modifications to the image and rewrite the file.
Once you have "fixjpeg" working, you can test your modified images with desktop applications such as GIMP, PhotoShop, Preview (Mac) or the major Browsers (Firefox, Edge, Chrome, Safari). When your image is acceptable to them, please open a new issue with your modified sample image and your request will be reconsidered.
I'm going to close this PR.