[PHP-DEV] GetImageSize,read_exif_data,Bug #6787,#14994
Hi Rasmus,
today i woke up and i think the solution is to have read_exif_data
a third parameter whether or not to return information if no exif is
present. And to support TIFFs with GetImageSize we only need
a small addition of say less than 100 lines c code...
marcus
--
[sorry first one has gone to wrong mailing list - so here again]
Hi Rasmus,
i think Serge is correct because one can use standard functions for
FileName,FileDateTime and FileSize. So better reply with false.
The other solution would be adding an array entry 'EXIFPresent' (true|false)
BUT i think that is not so good.
From my point of view i would like to discuss the difference between
getimagesize and read_exif_data a little:
We would need some function*ality* from exif.c in image.c to support TIFF.
When we have those functions we would be able to interpret APP markers
of JPEG also (see below).
I suppose we check whether or not ext/exif is present and then return
read_exif_data results in GetImageSize (i do not see the point of returning
and APP marker section which has to be interpreted). Then we should also
make ext/exif default to present and change switch from --enable-exif to
--disable-exif (prefer this).
Or we move the necessary functions from exif.c to image.c and
then make ext/exif optional for editing exif headers in the future.
If to many people use APP return info we could use a third parameter to
return interpreted values.
The real point here is that i do not know what APP markers and EXIF
headers have to do with GetImageSize but we have the information when
adding TIFF support.
what do you think?
marcus
---
#6787
[17 Sep 2000 6:07am] [EMAIL PROTECTED]
Hi Guys,
It seems that read_exif_data builds certain fields like
FileName, FileDateTime, FileSize etc .. even when no real
EXIF data exists. So read_exif_data will always return something!
This makes it a pain to test for the presence of actual EXIF data cause
I have to do something like this:
$exif_data = @read_exif_data($upload);
if (isset ($exif_data['CameraMake'])) {
Not very bullet proof
Would be nice if it would not return anything without the presence of
actual EXIF data.
Thanks, Serge
#14994
[11 Jan 6:07am] [EMAIL PROTECTED]
I know, that Rasmus made the implementation for this function and that
he used the header readouts from an imageinfo.c, but I'm missing the
ability to identify TIFF images.
As i'm not firm with imageheaders, I'd like to ask someone to implement
this feature.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GetImageSize,read_exif_data,Bug #6787,#14994
Marcus Boerger wrote:
Hi Rasmus,
today i woke up and i think the solution is to have read_exif_data
a third parameter whether or not to return information if no exif is
present. And to support TIFFs with GetImageSize we only need
a small addition of say less than 100 lines c code...
marcus
--
[sorry first one has gone to wrong mailing list - so here again]
Hi Rasmus,
i think Serge is correct because one can use standard functions for
FileName,FileDateTime and FileSize. So better reply with false.
The other solution would be adding an array entry 'EXIFPresent' (true|false)
BUT i think that is not so good.
From my point of view i would like to discuss the difference between
getimagesize and read_exif_data a little:
We would need some function*ality* from exif.c in image.c to support TIFF.
When we have those functions we would be able to interpret APP markers
of JPEG also (see below).
I suppose we check whether or not ext/exif is present and then return
read_exif_data results in GetImageSize (i do not see the point of returning
and APP marker section which has to be interpreted). Then we should also
make ext/exif default to present and change switch from --enable-exif to
--disable-exif (prefer this).
Or we move the necessary functions from exif.c to image.c and
then make ext/exif optional for editing exif headers in the future.
If to many people use APP return info we could use a third parameter to
return interpreted values.
The real point here is that i do not know what APP markers and EXIF
headers have to do with GetImageSize but we have the information when
adding TIFF support.
what do you think?
marcus
---
#6787
[17 Sep 2000 6:07am] [EMAIL PROTECTED]
Hi Guys,
It seems that read_exif_data builds certain fields like
FileName, FileDateTime, FileSize etc .. even when no real
EXIF data exists. So read_exif_data will always return something!
This makes it a pain to test for the presence of actual EXIF data cause
I have to do something like this:
$exif_data = @read_exif_data($upload);
if (isset ($exif_data['CameraMake'])) {
Not very bullet proof
Would be nice if it would not return anything without the presence of
actual EXIF data.
Thanks, Serge
#14994
[11 Jan 6:07am] [EMAIL PROTECTED]
I know, that Rasmus made the implementation for this function and that
he used the header readouts from an imageinfo.c, but I'm missing the
ability to identify TIFF images.
As i'm not firm with imageheaders, I'd like to ask someone to implement
this feature.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Marcus, Rasmus,
I'm rather new to this list, just lurking for some time now. Please
excuse me, if this is slightly off topic.
I've come across some weird results from GetImageSize() in $info[]
myself and have sent a comment w/ patch to bugs #15174 and #13213 of
which the latter is not that important IMO.
On the topic of EXIF headers:
The ext/exif/exif.c code does basically the same as in standard/image.c:
it parses the JPEG header structure and extracts the different markers.
In image.c we have a function iptcparse(), which further interprets the
APP13 markers content. In ext/exif/exif.c there is read_exif_data().
Since the EXIF header is identical to the APP1 marker (M_EXIF == M_APP1
== 0xe1), why not have a function exifparse() in standard/image.c which
will interpret the APP1 (aka EXIF header) marker's content and get rid
of ext/exif?
AFAIK there's a third data structure in the JPEG headers which might
become interesting to image processing apps in the future: the APP2
marker contains ICC profiles, which are needed for color management ...
Adding TIFF support:
A corresponding situation exists when adding TIFF support. Tags in TIFF
hold analogous data to the JPEG markers, especially the above mentionend
substructures will be present. So wouldn't it be great to call
GetImageSize() on a TIFF and return $info[], which has elements
$info[IPTC], $info[EXIF] and info[ICC] reliably set?
HTH ... Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GetImageSize,read_exif_data,Bug #6787,#14994
At 22:04 03.03.2002, Michael Ulbrich wrote:
Ah - not off topic
Comment on : Tags in TIFF hold analogous data to the JPEG markers,
Its just the other way round JPEG APP1 sections contains a TIFF header
including IFD0 structure and TIFF6.0 Tags.
As i wrote today morgning (my one) i would prefer adding TIFF support
for GetImageSize and leave it as it is besides that. The new exif module
has some extensions, maybe i split up the information to seperate arrays
to inform where the data comes from...but next version.
marcus
Marcus Boerger wrote:
Hi Rasmus,
today i woke up and i think the solution is to have read_exif_data
a third parameter whether or not to return information if no exif is
present. And to support TIFFs with GetImageSize we only need
a small addition of say less than 100 lines c code...
marcus
--
[sorry first one has gone to wrong mailing list - so here again]
Hi Rasmus,
i think Serge is correct because one can use standard functions for
FileName,FileDateTime and FileSize. So better reply with false.
The other solution would be adding an array entry 'EXIFPresent'
(true|false)
BUT i think that is not so good.
From my point of view i would like to discuss the difference between
getimagesize and read_exif_data a little:
We would need some function*ality* from exif.c in image.c to support TIFF.
When we have those functions we would be able to interpret APP markers
of JPEG also (see below).
I suppose we check whether or not ext/exif is present and then return
read_exif_data results in GetImageSize (i do not see the point of returning
and APP marker section which has to be interpreted). Then we should also
make ext/exif default to present and change switch from --enable-exif to
--disable-exif (prefer this).
Or we move the necessary functions from exif.c to image.c and
then make ext/exif optional for editing exif headers in the future.
If to many people use APP return info we could use a third parameter to
return interpreted values.
The real point here is that i do not know what APP markers and EXIF
headers have to do with GetImageSize but we have the information when
adding TIFF support.
what do you think?
marcus
---
#6787
[17 Sep 2000 6:07am] [EMAIL PROTECTED]
Hi Guys,
It seems that read_exif_data builds certain fields like
FileName, FileDateTime, FileSize etc .. even when no real
EXIF data exists. So read_exif_data will always return something!
This makes it a pain to test for the presence of actual EXIF data cause
I have to do something like this:
$exif_data = @read_exif_data($upload);
if (isset ($exif_data['CameraMake'])) {
Not very bullet proof
Would be nice if it would not return anything without the presence of
actual EXIF data.
Thanks, Serge
#14994
[11 Jan 6:07am] [EMAIL PROTECTED]
I know, that Rasmus made the implementation for this function and that
he used the header readouts from an imageinfo.c, but I'm missing the
ability to identify TIFF images.
As i'm not firm with imageheaders, I'd like to ask someone to implement
this feature.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Marcus, Rasmus,
I'm rather new to this list, just lurking for some time now. Please
excuse me, if this is slightly off topic.
I've come across some weird results from GetImageSize() in $info[]
myself and have sent a comment w/ patch to bugs #15174 and #13213 of
which the latter is not that important IMO.
On the topic of EXIF headers:
The ext/exif/exif.c code does basically the same as in standard/image.c:
it parses the JPEG header structure and extracts the different markers.
In image.c we have a function iptcparse(), which further interprets the
APP13 markers content. In ext/exif/exif.c there is read_exif_data().
Since the EXIF header is identical to the APP1 marker (M_EXIF == M_APP1
== 0xe1), why not have a function exifparse() in standard/image.c which
will interpret the APP1 (aka EXIF header) marker's content and get rid
of ext/exif?
AFAIK there's a third data structure in the JPEG headers which might
become interesting to image processing apps in the future: the APP2
marker contains ICC profiles, which are needed for color management ...
Adding TIFF support:
A corresponding situation exists when adding TIFF support. Tags in TIFF
hold analogous data to the JPEG markers, especially the above mentionend
substructures will be present. So wouldn't it be great to call
GetImageSize() on a TIFF and return $info[], which has elements
$info[IPTC], $info[EXIF] and info[ICC] reliably set?
HTH ... Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
