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

Reading Exif Data Fails #44

Closed
tehprofessor opened this issue Jul 26, 2013 · 17 comments
Closed

Reading Exif Data Fails #44

tehprofessor opened this issue Jul 26, 2013 · 17 comments
Labels

Comments

@tehprofessor
Copy link
Contributor

Howdy,

When I attempt read EXIF data from an image, it fails with:

img.get('exif-Orientation')
VIPS::Error: VIPS error: vips_image_get: field "exif-Orientation" not found

I've attached the image in question:

tall-iphone-photo

If I use header -a tall-iphone-photo.jpg it works and I get:

tall-iphone-photo.jpg: 3264x2448 uchar, 3 bands, srgb, partial VipsImage (0x7ff54b03e030)
width: 3264
height: 2448
bands: 3
format: 0 - uchar
coding: 0 - none
interpretation: 22 - srgb
xoffset: 0
yoffset: 0
xres: 2.834646
yres: 2.834646
filename: "tall-iphone-photo.jpg"
jpeg-multiscan: 0
exif-data: VIPS_TYPE_BLOB, data = 0x7ff54b048600, length = 12284
exif-Manufacturer: Apple (Apple, ASCII, 6 components, 6 bytes)
exif-Model: iPhone 5 (iPhone 5, ASCII, 9 components, 9 bytes)
exif-Orientation: 6 (Right-top, Short, 1 components, 2 bytes)
exif-Software: 6.1.4 (6.1.4, ASCII, 6 components, 6 bytes)
exif-Date and Time: 2013:07:24 15:18:39 (2013:07:24 15:18:39, ASCII, 20 components, 20 bytes)
exif-YCbCr Positioning: 1 (Centered, Short, 1 components, 2 bytes)
exif-Compression: 6 (JPEG compression, Short, 1 components, 2 bytes)
exif-X-Resolution: 72 (72, Rational, 1 components, 8 bytes)
exif-Y-Resolution: 72 (72, Rational, 1 components, 8 bytes)
exif-Resolution Unit: 2 (Inch, Short, 1 components, 2 bytes)
exif-Exposure Time: 0.050000000000000003 (1/20 sec., Rational, 1 components, 8 bytes)
exif-F-Number: 2.3999999999999999 (f/2.4, Rational, 1 components, 8 bytes)
exif-Exposure Program: 2 (Normal program, Short, 1 components, 2 bytes)
exif-ISO Speed Ratings: 64 (64, Short, 1 components, 2 bytes)
exif-Exif Version: Exif Version 2.21 (Exif Version 2.21, Undefined, 4 components, 4 bytes)
exif-Date and Time (Original): 2013:07:24 15:18:39 (2013:07:24 15:18:39, ASCII, 20 components, 20 bytes)
exif-Date and Time (Digitized): 2013:07:24 15:18:39 (2013:07:24 15:18:39, ASCII, 20 components, 20 bytes)
exif-Components Configuration: Y Cb Cr - (Y Cb Cr -, Undefined, 4 components, 4 bytes)
exif-Shutter Speed: 4.3219567690557454 (4.32 EV (1/20 sec.), SRational, 1 components, 8 bytes)
exif-Aperture: 2.5260688216892597 (2.53 EV (f/2.4), Rational, 1 components, 8 bytes)
exif-Brightness: 2.6485933503836319 (2.65 EV (21.48 cd/m^2), SRational, 1 components, 8 bytes)
exif-Metering Mode: 5 (Pattern, Short, 1 components, 2 bytes)
exif-Flash: 24 (Flash did not fire, auto mode, Short, 1 components, 2 bytes)
exif-Focal Length: 4.1299999999999999 (4.1 mm, Rational, 1 components, 8 bytes)
exif-Subject Area: 1631 1223 881 881 (Within rectangle (width 881, height 881) around (x,y) = (1631,1223), Short, 4 components, 8 bytes)
exif-FlashPixVersion: FlashPix Version 1.0 (FlashPix Version 1.0, Undefined, 4 components, 4 bytes)
exif-Color Space: 1 (sRGB, Short, 1 components, 2 bytes)
exif-Pixel X Dimension: 3264 (3264, Long, 1 components, 4 bytes)
exif-Pixel Y Dimension: 2448 (2448, Long, 1 components, 4 bytes)
exif-Sensing Method: 2 (One-chip color area sensor, Short, 1 components, 2 bytes)
exif-Exposure Mode: 0 (Auto exposure, Short, 1 components, 2 bytes)
exif-White Balance: 0 (Auto white balance, Short, 1 components, 2 bytes)
exif-Focal Length in 35mm Film: 33 (33, Short, 1 components, 2 bytes)
exif-Scene Capture Type: 0 (Standard, Short, 1 components, 2 bytes)
exif-Interoperability Index: N (N, ASCII, 2 components, 2 bytes)
exif-Interoperability Version: 45 31.5 0 (45, 31.50,  0, Rational, 3 components, 24 bytes)
exif-East or West Longitude: W (W, ASCII, 2 components, 2 bytes)
exif-Longitude: 122 41.079999999999998 0 (122, 41.08,  0, Rational, 3 components, 24 bytes)
exif-Altitude Reference: Sea level (Sea level, Byte, 1 components, 1 bytes)
exif-Altitude: 18.448275862068964 (18.45, Rational, 1 components, 8 bytes)
exif-GPS Time (Atomic Clock): 22 18 38.43 (22:18:38.43, Rational, 3 components, 24 bytes)
exif-GPS Image Direction Reference: T (T, ASCII, 2 components, 2 bytes)
exif-GPS Image Direction: 281.27149321266967 (281.271, Rational, 1 components, 8 bytes)
resolution-unit: in
jpeg-thumbnail-data: VIPS_TYPE_BLOB, data = 0x7ff54b04d600, length = 8174

I'm not sure if I'm doing something wrong? I've tried it using libvips versions vips-7.32.2 and vips-7.34.1 on Debian Wheezy (7.1).

Any help would be greatly appreciated. The goal is to orient the photo, then remove the exif-orientation data, so that it displays the same on all browsers-- maybe there's a built in way to do this already?

Best,
Seve

Update

The plot thickens, if I use vips version 7.30.2, on OS X, then I get:

img.get('exif-Orientation')
=> "6 (Right-top, Short, 1 components, 2 bytes)"

I'm going to install 7.30.2 on my Debian machine and see if it fixes it.

@tehprofessor
Copy link
Contributor Author

Howdy,

Also out of curiosity, how would I go about reading/understanding this the output of .exif? Please pardon my n00bness.

Best,
Seve

@jcupitt
Copy link
Member

jcupitt commented Jul 26, 2013

Oh, strange, it should work. I'll have a look.

@tehprofessor
Copy link
Contributor Author

Thank you, much! I just noticed that fields which aren't prefixed with 'exif-' seem to work fine, with the notable exception of 'exif-data' which works fine...

@jcupitt
Copy link
Member

jcupitt commented Jul 27, 2013

It could be a linking problem. Perhaps libvips is built against libexif but
rubyvips is not?

On Friday, 26 July 2013, Seve Salazar wrote:

Thank you, much! I just noticed that fields which aren't prefixed with
'exif-' seem to work fine, with the notable exception of 'exif-data' which
works fine...


Reply to this email directly or view it on GitHubhttps://github.com//issues/44#issuecomment-21652588
.

@jcupitt
Copy link
Member

jcupitt commented Jul 27, 2013

It could also be a version mismatch. I think your ruby-vips and your command-line vips are using different versions of libvips, causing confusion.

The latest libvips includes the ifd number in the exif field. This was necessary to correctly pass all exif data, since (crazily) you can have the same field in several ifds with different values and apparently that's fine.

Try:

irb(main):121:0* fred = VIPS::Image.new("/home/john/pics/img_0075.jpg")
=> #<VIPS::Image:0x000000017a3310>
irb(main):124:0> fred.get("exif-ifd0-Orientation")
=> "1 (Top-left, Short, 1 components, 2 bytes)"
irb(main):127:0> fred.set("exif-ifd0-Orientation", "4")
=> nil
irb(main):128:0> fred.write("a.jpg")

then:

$ header -a a.jpg
a.jpg: 1600x1200 uchar, 3 bands, srgb, jpegload
width: 1600
...
exif-ifd0-Model: Canon DIGITAL IXUS 300 (Canon DIGITAL IXUS 300, ASCII, 23 components, 23 bytes)
exif-ifd0-Orientation: 4 (Bottom-left, Short, 1 components, 2 bytes)
exif-ifd0-X-Resolution: 180/1 (180, Rational, 1 components, 8 bytes)
...

@tehprofessor
Copy link
Contributor Author

That makes a lot of sense actually, to both comments. Ill give em a shot in the morning (I'm on the west coast of the US). We've just migrated our development environment to virtual machines, and I'm willing to bet this is a side effect as it works fine on the host system (OS X).

If I get this settled tomorrow I'll close the ticket... Or at the very least update it, with what I've tried. Lastly if you don't mind, I'd like write a doc about it if its an environment issue! I sadly don't know C or C++ so I'd like to contribute what I can to the project (documentation).

@jcupitt
Copy link
Member

jcupitt commented Jul 27, 2013

Look around the github wiki, there should be somewhere to add it. I'm on
holiday this week with only edge access so I can't easily point you to a
good spot.

On Saturday, 27 July 2013, Seve Salazar wrote:

That makes a lot of sense actually, to both comments. Ill give em a shot
in the morning (I'm on the west coast of the US). We've just migrated our
development environment to virtual machines, and I'm willing to bet this is
a side effect as it works fine on the host system (OS X).

If I get this settled tomorrow I'll close the ticket... Or at the very
least update it, with what I've tried. Lastly if you don't mind, I'd like
write a doc about it if its an environment issue! I sadly don't know C or
C++ so I'd like to contribute what I can to the project (documentation).


Reply to this email directly or view it on GitHubhttps://github.com//issues/44#issuecomment-21662553
.

@nishantrayan
Copy link

hi @tehprofessor I am running into the same issue. Can you post what you have tried and if it worked?
Thanks.

@tehprofessor
Copy link
Contributor Author

Howdy!

I should've followed through on on updating this, sorry!

@jcupitt Was spot on. The issue for me was from a mismatched versions of vips, its dependencies, and ruby-vips. It came from upgrading, rather haphazardly (I now know), over time. Upon removing vips, it's dependencies, and reinstalling it all (and rubyvips) everything was fine. Rather painless, and I should've just done it to begin with.

Also, @jcupitt I looked at the Wiki and how would you feel about a Troubleshooting, Common Problems, FAQ (?) page?

E.g.

Common Problems

Reading Exif data throws an error

Example Code

img = VIPS::Image.new("img.jpg")
img.get('exif-Orientation')
VIPS::Error: VIPS error: vips_image_get: field "exif-Orientation" not found

This is most commonly a result of a mismatched version of ruby vips and libvips. It is recommended to remove both, and reinstall. Generally speaking, this is a result of upgrading rubyvips without upgrading libvips and/or its dependencies.

Originally discussed: #44

@jcupitt
Copy link
Member

jcupitt commented Aug 27, 2013

Good idea, I made this page:

https://github.com/jcupitt/ruby-vips/wiki/Troubleshooting

Feel free to add any more tips there.

@nishantrayan
Copy link

@jcupitt thanks for the response. I started learning about vips recently and just getting the hang of if when I ran into the problem. Can you help me with how to go about the re installation.I installed libvips using apt-get and ruby-vips using gem install.. Should i just do apt-get remove and gem uninstall and install again? Is that what you are recommending.?
My basic problem is that I get an error when I do,
image.get("exif-ifd0-Orientation")
and
image.get("exif-Orientation")
I am able to see the exif-ifd0-Orientation in header -a a.jpg on osx

@jcupitt
Copy link
Member

jcupitt commented Aug 27, 2013

First check that your libvips has exif working correctly. Try:

header -a somefile.jpg

and make sure the exif fields are showing up.

Now uninstall and reinstall ruby-vips and try reading the fields using the names as they appear in the output of "header".

@nishantrayan
Copy link

I am on ubuntu. I used the jhead command to verify the header,
Among the output there was,
Orientation : rotate 90
Does this mean libvips is working in libexif ? is there an alternate tool for header in ubuntu?

@jcupitt
Copy link
Member

jcupitt commented Aug 28, 2013

There are several libvips packages. libvips-tools includes the "header" program, which displays image header fields using libvips. Try using that and verify that you see exif stuff.

@nishantrayan
Copy link

I coudn't find the header program in libvips-tools,
When I run 'dpkg -L libvips-tools' after install libvips-tools this is what I get,

/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libvips-tools
/usr/share/doc/libvips-tools/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/batch_rubber_sheet.1.gz
/usr/share/man/man1/edvips.1.gz
/usr/share/man/man1/light_correct.1.gz
/usr/share/man/man1/vips.1.gz
/usr/share/man/man1/vipsthumbnail.1.gz
/usr/share/man/man1/find_mosaic.1.gz
/usr/share/man/man1/mergeup.1.gz
/usr/share/man/man1/shrink_width.1.gz
/usr/share/man/man1/vips-7.26.1.gz
/usr/share/man/man1/batch_crop.1.gz
/usr/share/man/man1/batch_image_convert.1.gz
/usr/share/man/man1/vips_missing.1.gz
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libvips-tools
/usr/bin
/usr/bin/find_mosaic
/usr/bin/mergeup
/usr/bin/vips
/usr/bin/edvips
/usr/bin/vipsthumbnail
/usr/bin/light_correct
/usr/bin/shrink_width
/usr/bin/batch_image_convert
/usr/bin/batch_rubber_sheet
/usr/bin/batch_crop
/usr/bin/vips-7.26
/usr/share/doc/libvips-tools/NEWS.gz
/usr/share/doc/libvips-tools/AUTHORS
/usr/share/doc/libvips-tools/THANKS
/usr/share/doc/libvips-tools/README.gz
/usr/share/doc/libvips-tools/TODO.gz
/usr/share/doc/libvips-tools/changelog.Debian.gz

Let me know if you want me a file a separate issue for this.. I have been struggling to get ruby-vips recognize exif headers for the last 2 days without any luck. I really don't want to use another library / gem for just manipulating exif headers as we have already been using ruby-vips for some other image processing jobs.
I would really appreciate your help with this. Thanks.

@jcupitt
Copy link
Member

jcupitt commented Aug 28, 2013

Sorry, I hadn't realized that "header" wasn't packaged. I'll install 7.26 here and verify everything.

@jcupitt
Copy link
Member

jcupitt commented Aug 29, 2013

I wiped everything and rebuilt with 7.26, it seems to work here:

https://gist.github.com/jcupitt/6376738

I did have some problems when I had several libvipses installed, it seems "gem install" will try to use the system libvips ahead of one installed to a private prefix. Make sure you only have one libvips around and that ruby picks up the right one.

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

No branches or pull requests

3 participants