Exif metadata with Lucee
139 views
Skip to first unread message
Max Spicer
Nov 27, 2015, 12:34:03 PM11/27/15
to lu...@googlegroups.com
Lucee seems to handle exif metadata differently to ColdFusion. Coldfusion allows exif tags to be accessed by their names defined in the standard, but these seem to be changed in Lucee. For example, the orientation tag cannot be read in Lucee, and you have to use imageorientation instead. The resolutionunit tag has become "resolution units".
I'm accessing these with code such as:
<cfset x = ImageGetExifTag("resolution units")>
<cfset x = ImageGetExifTag("imageorientation")>
The full list can be seen with ImageGetExifMetadata() and returns a strange mix of field names, that vary wildly in convention. Example:
acHuffTable
alpha_channel_support
Compression Type
CompressionTypeName
Xdensity
Is this deviation from ColdFusion (and the exif standard?) intentional? Is it documented anywhere?
Cheers,
Max
Andrew Dixon
Nov 27, 2015, 4:21:04 PM11/27/15
to lu...@googlegroups.com
Hi Max,
Interesting you mention this as I've recently been having a problem with a script that reorientates images based on the EXIF metadata and it not orientating it right in some cases, this might go some way to explaining it. I will investigate this further and get back to you when I have some answers. I'm wondering if ACF normalises the EXIF data and Lucee is just presenting the raw data or something like that. I'm not really that up to speed on EXIF and how standardised it is.
--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Andrew Dixon
Nov 28, 2015, 2:30:47 PM11/28/15
to lu...@googlegroups.com
Hi Max,
From my brief investigation into some images I'm been having problems with, it would appear that you are right in that there is a lot of random EXIF data returned but this appears to be because there is not really any standard with EXIF and you can pretty much just chuck in any old tag you like with a value, so different cameras from different manufactures produce widely varying EXIF data, both in keys and values, particularly it would appear when it comes to image orientation. I'm not sure what ACF is doing but I assume it is normalising the EXIF data before returning it and Lucee is simply returning the raw EXIF data from the file. I will investigate further and see if I can find out how ACF is doing this and if it would be something Lucee can implement easily.
Andrew Dixon
Nov 28, 2015, 3:27:49 PM11/28/15
to lu...@googlegroups.com
Hi Max,
After doing some more testing with ACF and Lucee on the same file, it would appear that Lucee is actually not returning EXIF data that exists in the image and ACF is. Lucee appears to return a lot of data points about the image that aren't actually EXIF data but just information about the image. These might be part of the EXIF data (I'm not sure), but it certainly isn't returning some of the data that is actually there. I have therefore raised a ticket for this:
Michael Sprague
Nov 28, 2015, 3:47:34 PM11/28/15
to lucee
This is an older project but maybe it will help with alternative options to the built in functions:
http://imagemetadata.riaforge.org/
Warm regards,
Mike
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG1WijU%2BJiuG%2B_KRK2xD7zhb_cLr8TKjRWNaVYg2TaKW_sDmrQ%40mail.gmail.com.
Max Spicer
Nov 30, 2015, 7:01:06 AM11/30/15
to lu...@googlegroups.com
Hi,
That's great news, Andrew. Thanks for your effort on this so far!
After some investigation of my own, I can report that Lucee currently only returns an orientation field if the image has been rotated, whereas it is always present with ACF. Using the sample images from https://github.com/recurser/exif-orientation-examples, Lucee returns similar orientation values to ACF. For all rotated images (ie not Landscape_1.jpg or Portrait_1.jpg), Lucee's orientation field starts the same as ACF's (ignoring case), but has additional information at the end. Here's some examples, again using the sample images from above.
images/Landscape_1.jpg
acf orientation: top, left side
lucee orientation: field absent
images/Landscape_2.jpg
acf orientation: top, right side
lucee orientation: Top, right side (Mirror horizontal)
images/Landscape_3.jpg
acf orientation: bottom, right side
lucee orientation: Bottom, right side (Rotate 180)
images/Landscape_4.jpg
acf orientation: bottom, left side
lucee orientation: Bottom, left side (Mirror vertical)
images/Landscape_5.jpg
acf orientation: left side, top
lucee orientation: Left side, top (Mirror horizontal and rotate 270 CW)
etc
It would ease porting from ACF if these values could be the same.
The EXIF standard does appear to define integer values for the orientation field, which would be much safer to work with in code than the text values above. These are given at http://www.exiv2.org/Exif2-2.PDF in section 4.6.4 A (page 18), as follows:
1 = The 0th row is at the visual top of the image, and the 0th column is the visual left-hand side.
2 = The 0th row is at the visual top of the image, and the 0th column is the visual right-hand side.
3 = The 0th row is at the visual bottom of the image, and the 0th column is the visual right-hand side.
4 = The 0th row is at the visual bottom of the image, and the 0th column is the visual left-hand side.
5 = The 0th row is the visual left-hand side of the image, and the 0th column is the visual top.
6 = The 0th row is the visual right-hand side of the image, and the 0th column is the visual top.
7 = The 0th row is the visual right-hand side of the image, and the 0th column is the visual bottom.
8 = The 0th row is the visual left-hand side of the image, and the 0th column is the visual bottom.
Other = reserved
I wonder if Lucee could introduce a way to get to the raw integer values, whilst keeping the text versions that ACF and Lucee already expose?
Max
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG1WijU%2BJiuG%2B_KRK2xD7zhb_cLr8TKjRWNaVYg2TaKW_sDmrQ%40mail.gmail.com.
Andrew Dixon
Nov 30, 2015, 8:01:58 AM11/30/15
to lu...@googlegroups.com
Hi Max,
If you take a look at https://luceeserver.atlassian.net/browse/LDEV-652 you will see I've submitted a pull request for this, however it is simply an update to an existing JAR and adding in a missing JAR, so basically download the two JAR and copy them to the "lib" directory on your installation, overwriting the metadata-extract.jar and adding the xmpcore.jar (FYI, you need to removed the version numbers from the file names once you have downloaded them). The download links are:
I've done this update on my test and production servers and not had any issues.
With regards to your point, I'm not sure why these would be difference between ACF and Lucee as both are using the metadata-extractor library (https://github.com/drewnoakes/metadata-extractor) to extract the values, maybe the update will fix this for you.
With regards to getting the raw integer values, Lucee is getting everything that metadata-extractor returns, so I'm guessing it doesn't return them.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CABbdpz8y51aRBMhm3M24%2BcaWfFe7iiECY9mh00DeV%2BZmV_spJA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages