Exif metadata with Lucee

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

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.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.orgOn 27 November 2015 at 17:33, Max Spicer <@Max_Spicer> wrote:

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


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Hi Max,

This is an older project but maybe it will help with alternative options to
the built in functions:

http://imagemetadata.riaforge.org/

Warm regards,

MikeOn Nov 28, 2015 3:27 PM, “Andrew Dixon” <@Andrew_Dixon> wrote:

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:

https://luceeserver.atlassian.net/browse/LDEV-652

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 28 November 2015 at 19:30, Andrew Dixon <@Andrew_Dixon> wrote:

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.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 27 November 2015 at 21:21, Andrew Dixon <@Andrew_Dixon> wrote:

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.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 27 November 2015 at 17:33, Max Spicer <@Max_Spicer> wrote:

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


Love Lucee? Become a supporter and be part of the Lucee project today!


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG1WijU%2BJiuG%2B_KRK2xD7zhb_cLr8TKjRWNaVYg2TaKW_sDmrQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG1WijU%2BJiuG%2B_KRK2xD7zhb_cLr8TKjRWNaVYg2TaKW_sDmrQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

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:

https://luceeserver.atlassian.net/browse/LDEV-652

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.orgOn 28 November 2015 at 19:30, Andrew Dixon <@Andrew_Dixon> wrote:

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.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 27 November 2015 at 21:21, Andrew Dixon <@Andrew_Dixon> wrote:

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.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 27 November 2015 at 17:33, Max Spicer <@Max_Spicer> wrote:

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


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

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?

MaxOn 28 November 2015 at 20:27, Andrew Dixon <@Andrew_Dixon> wrote:

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:

https://luceeserver.atlassian.net/browse/LDEV-652

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 28 November 2015 at 19:30, Andrew Dixon <@Andrew_Dixon> wrote:

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.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 27 November 2015 at 21:21, Andrew Dixon <@Andrew_Dixon> wrote:

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.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 27 November 2015 at 17:33, Max Spicer <@Max_Spicer> wrote:

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


Love Lucee? Become a supporter and be part of the Lucee project today!


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG1WijU%2BJiuG%2B_KRK2xD7zhb_cLr8TKjRWNaVYg2TaKW_sDmrQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG1WijU%2BJiuG%2B_KRK2xD7zhb_cLr8TKjRWNaVYg2TaKW_sDmrQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

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:

http://search.maven.org/remotecontent?filepath=com/drewnoakes/metadata-extractor/2.8.1/metadata-extractor-2.8.1.jar
http://search.maven.org/remotecontent?filepath=com/adobe/xmp/xmpcore/5.1.2/xmpcore-5.1.2.jar

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.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.orgOn 30 November 2015 at 12:00, Max Spicer <@Max_Spicer> wrote:

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

On 28 November 2015 at 20:27, Andrew Dixon <@Andrew_Dixon> wrote:

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:

https://luceeserver.atlassian.net/browse/LDEV-652

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 28 November 2015 at 19:30, Andrew Dixon <@Andrew_Dixon> wrote:

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.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 27 November 2015 at 21:21, Andrew Dixon <@Andrew_Dixon> wrote:

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.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org

On 27 November 2015 at 17:33, Max Spicer <@Max_Spicer> wrote:

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


Love Lucee? Become a supporter and be part of the Lucee project today!


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABbdpz9E8EOkiDGiu1cbd9LgOZkqoHijC0tTMYmd28%3Dq143odg%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG1WijU%2BJiuG%2B_KRK2xD7zhb_cLr8TKjRWNaVYg2TaKW_sDmrQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG1WijU%2BJiuG%2B_KRK2xD7zhb_cLr8TKjRWNaVYg2TaKW_sDmrQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABbdpz8y51aRBMhm3M24%2BcaWfFe7iiECY9mh00DeV%2BZmV_spJA%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABbdpz8y51aRBMhm3M24%2BcaWfFe7iiECY9mh00DeV%2BZmV_spJA%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.