Open TheZoq2 opened 7 years ago
That's interesting. I was under impression that EXIF is not an alternative encoding of JPEG but rather a part of the main container, and its data is completely auxiliary. I wonder why cameras do not fill the standard JFIF fields, they seem necessary for image processing to me. I'll check it against some photos, thanks.
Also, in fact, I've implemented a TIFF parser here, all that's left is to use it in the JPEG decoder to parse the EXIF. That's on my todo list.
As for #1, that was not an implementation which could be merged directly, and apparently its author decided against sending a PR for some reason, so we couldn't iterate over to fix all problems there :) Since the code has changed since then it is unlikely that I'll be able to merge that code directly.
Yea, I was surprised by that aswell. However, according to something I read, both exif and jfif expect have their header in the first APPn section. Luckily they use different n which allows them to be in the same file together even though the requirement to be first can't be satisfied. My phone seems to export both EXIF and JFIF but my nikon camera does not.
If you want me to, I could look into integrating that TIFF parser in the JPEG parser in a few days when im done with exams.
Thanks for the suggestion! Actually, I would very much like to finish the tests for the TIFF parser first. It is quite a complex format, and I'm not entirely sure that I got it right on the first try. There is a already a large test which checks a single IFD of various types, but I need more, in particular, with multiple IFDs. At the end of the module file I wrote out some test scenarios I find useful but which have to be done yet. If you want, you can look into this.
@TheZoq2, just to make sure,
dimensions returned are wrong
how exactly they are wrong? Is it only the height which is incorrect? If yes, then it may be caused by the fact that the image height may be written in two places in a JPEG file, and the second one is not supported in the master branch. This is not actually related to the interchange format because immeta does not analyze APP0, it extracts the dimensions directly from the SOF marker, which seems to be required for every kind of JPEG picture.
It depends. It seems like for some pictures it reads the thumbnail dimensions and for some pictures it reads seemingly random value that is around about 10000x10000 with the wrong aspect ration. This is for different images comming off the same camera that are all 6000x4000.
Here are two images that have the wrong size. DSC_0001
reads 57379x58117
while the other one reads 160x120
https://drive.google.com/drive/folders/0B-ZjOK5GhXS_VVlucmRUWDhYZWc?usp=sharing
Oh wow, thanks, I'll look into it.
When loading some jpg images, the dimensions returned are wrong. After looking into it it seems like images that are encoded as JFIF work fine but images encoded as EXIF which a lot of cameras use doesn't work.
Im trying to write a fix for this but I figgured I should report the issue here in case someone else runs into the same problem
Edit: Looks like @tdryer has already implemented exif parsing as discussed in #1. Is there a reason that it hasn't been merged yet?