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

Allow parsing a straight EXIF buffer instead of requiring an image #15

Open
wants to merge 22 commits into
base: master
Choose a base branch
from

Conversation

sujal
Copy link

@sujal sujal commented Jun 14, 2013

Hi there. This pull request looks big, but it really isn't - there are a lot of whitespace changes that cloud the default diff view.

Two major changes:

  1. Allow the use of an exif buffer, not just a image buffer or file. This has the nice advantage of being able to read EXIF out of a network stream. See my module node-image-headers for a use case.
  2. Re-add @DougReeder's tests. (they pass, too)

Let me know if you have any comments or concerns. I had a long-ago-forked version that I remerged your master into and brought back into line. I don't think any other changes crept in (they were mostly bug fixes from other pull requests that you've since merged).

DougReeder and others added 19 commits January 30, 2012 23:33
Pull in DougReeder's changes
This is useful for scenarios where another library is parsing the EXIF
data.
Well, it was probably busted for all cases, but I'm not sure if that's
true. basically, the != 0x00000000 test was broken. So, as long as there
as an IFD1 offset, the code worked fine.
…mfunkel-master

Conflicts:
	lib/exif/Buffer.js
	lib/exif/ExifImage.js
	lib/exif/makernotes/agfa.js
	lib/exif/makernotes/epson.js
	lib/exif/makernotes/olympus.js
I'm not sure exactly what the spec requires, but an offset of 0 seems
like a really odd choice for an IFD pointer in an exif block. In any
case, it was wrong in this particular file and other examples i can
find.
@sujal
Copy link
Author

sujal commented Jun 15, 2013

I just added another commit which fixes a bug if a file has a GPSInfo IFD entry with a value of 0. 0 doesn't make any sense, if I'm reading the spec correctly, so I explicitly check for > 0 in this commit.

If anyone is more of an expert on this, please correct me, but it seems like this might be a good sanity check for all the IFD pointers that are offset from the header.

@gomfunkel
Copy link
Owner

Thanks for the pull request, looks like some nice stuff in there!

I checked some of the changes and realized that I can't merge everything automatically. I will see to merge everything in the next couple of days.

@sujal
Copy link
Author

sujal commented Jun 27, 2013

@gomfunkel cool - let me know if you need anything from my end. Happy to help if I can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants