Proof corrups EXIF Tags

[cppcodeguru]

Hello,

I had an old version of BB Pro 1.7.0.x that corrupted the EXIF Tags, so I was thinking to buy an upgrade but the new version 1.7.3.1 does the same.
Here is the problem description:

On my website I read EXIF information from the pictures to display on the website with the commands:
$exif = exif_read_data($fp, 0, true);
if ( $exif['EXIF']['DateTimeDigitized'] != "" )
echo "\n
\n Timestamp: " . $exif['EXIF']['DateTimeDigitized'] . " GMT
";
if ( $exif['EXIF']['ISOSpeedRatings'] != "" )
echo "\n ISO: " . $exif['EXIF']['ISOSpeedRatings'] . "
";
...

If I resize a picture with Adobe Photoshop Elements and load it to the website all informations are displayed as well.
If I do a proof with bb pro and do a upload to my webspace the exif informations are corrupted (empty).

Is this a bug or a feature.

Thanks,

Andreas.

[DavidB]

If I do a proof with bb pro and do a upload to my webspace the EXIF informations are corrupted (empty).

Is this a bug or a feature?
If, in the Output box of the Proofs dialogue, you have (accidentally or otherwise) set the file format to 'JPEG (No EXIF)', it's a feature. Otherwise, it's a bug, but not one I have encountered.

If it does look like a bug, have you tried reading the EXIF information from the proofed file in BB Pro? If it doesn't show up in BB Pro, then it is certainly corrupt or absent. That would be the time to send a sample file to Chris for examination.

You do say that you are using the Proofs function rather than HTML generation; the latter omits the EXIF data from the files it generates, while Proofs (mostly) includes it.

Hope this helps.

[cppcodeguru]

If, in the Output box of the Proofs dialogue, you have (accidentally or otherwise) set the file format to 'JPEG (No EXIF)', it's a feature. Otherwise, it's a bug, but not one I have encountered.

If it does look like a bug, have you tried reading the EXIF information from the proofed file in BB Pro? If it doesn't show up in BB Pro, then it is certainly corrupt or absent. That would be the time to send a sample file to Chris for examination.

You do say that you are using the Proofs function rather than HTML generation; the latter omits the EXIF data from the files it generates, while Proofs (mostly) includes it.

Hope this helps.

Hello David,
the format was set to 'JPEG'.
I found that it is a problem with the bb function Edit IPCT/XMP data.

Sorry, it's not a problem of the EXIF its a problem with the IPCT/XMP data.
Before I have done a proof I set the IPCT/XMP data (Document Title, Autor and so on with bb) of the original picture. If I upload this picture to the server I get the following error:
Warning: exif_read_data(XXX.jpg): incorrect APP1 Exif Identifier Code

If I look at the IPCT/XMP data with bb or Adobe Photoshop Elements all seems o.k.
If I load and save the corrupt file with APSE the corrupt IPCT/XMP data is healed

So it is a problem with the bb function Edit IPCT/XMP data.

Yes, I use the proof function rather than HTML, because on my website I have a modified php script "Photo gallery by Forge22 Design" that is doing the job, I only have to drop the images in some directories on the webserver and thats all. The php script scans all subdirectories, generates a menue from the directories, creates preview images, shows EXIF information and so on.

If you want, have a look at:
http://www.schniertshauer.name/photogallery/andreas%20schniertshauer/?

Thanks for your fast reply,

Andreas.

[DavidB]

Andreas

If it's IPTC rather than EXIF data, the circumstances are somewhat different. Even so, if the suggestion that follows doesn't work, I still think you could usefully send a couple of images (one that works with the server and one that doesn't) to Chris at [email protected]. Unfortunately, Chris is on holiday (http://www.breezesys.com/forum/showthread.php?t=2674) this week - school holidays here in the UK.

BB Pro is, as far as I know, designed to be fully compliant with the IPTC/XMP standard. The error that comes from your server is not one that I would immediately associate with XMP (which, because it is written in XML, finds tags through the XML syntax rather than in defined memory blocks). This is only a guess, but I suspect your server may be looking for old standard (IPTC/IIM) rather than current (IPTC/XMP) data; IIM, like EXIF, does use defined memory offsets. And if your 'APSE' is Adobe Photoshop SE, then I believe that is basically IIM- rather than XMP-compliant, though your version clearly has some capability to read XMP, which was devised by Adobe.

One way to check this is to enable the option in BB Pro (on the General tab of Preferences) to save IPTC data in IIM as well as XMP format. Then edit and save IPTC data in a couple of images as normal, and see if the resultant images can be uploaded to your server.

If you already have the IIM option enabled, then my guess is that the problem is with the IIM rather than the XMP data. Then you could try disabling the option and saving the data only in XMP format, to see if your server can handle that.

I hope that this gives you some ideas to work on while Chris is away.

David

[cppcodeguru]

Andreas

If it's IPTC rather than EXIF data, the circumstances are somewhat different. Even so, if the suggestion that follows doesn't work, I still think you could usefully send a couple of images (one that works with the server and one that doesn't) to Chris at [email protected]. Unfortunately, Chris is on holiday (http://www.breezesys.com/forum/showthread.php?t=2674) this week - school holidays here in the UK.

BB Pro is, as far as I know, designed to be fully compliant with the IPTC/XMP standard. The error that comes from your server is not one that I would immediately associate with XMP (which, because it is written in XML, finds tags through the XML syntax rather than in defined memory blocks). This is only a guess, but I suspect your server may be looking for old standard (IPTC/IIM) rather than current (IPTC/XMP) data; IIM, like EXIF, does use defined memory offsets. And if your 'APSE' is Adobe Photoshop SE, then I believe that is basically IIM- rather than XMP-compliant, though your version clearly has some capability to read XMP, which was devised by Adobe.

One way to check this is to enable the option in BB Pro (on the General tab of Preferences) to save IPTC data in IIM as well as XMP format. Then edit and save IPTC data in a couple of images as normal, and see if the resultant images can be uploaded to your server.

If you already have the IIM option enabled, then my guess is that the problem is with the IIM rather than the XMP data. Then you could try disabling the option and saving the data only in XMP format, to see if your server can handle that.

I hope that this gives you some ideas to work on while Chris is away.

David

Hello,
with APSE I mean Adobe Photoshop Elements 4.0
I didn't have IIM enabled.

Now I tested it with and without IIM, it's allways the same, no data is diplayed.
If I load the pictures to Adobe Photoshop Elements 4.0 and save it again,
the data is available.

I put the four files to my webserver:
http://www.schniertshauer.name/photogallery/andreas%20schniertshauer/?d=delme&pg=&ig=3
There is 'Autor:' and 'Copyright:' at the bottom of the big pictures.
The filenames are ipct_iim and ipct_without_iim generated with bb pro 1.7.3.1.
The files with ...adobe are the bb generated files loaded to APSE 4.0 and saved again (nothing else done).

Andreas.

[cppcodeguru]

Hello,

exif_read_data() is available in (PHP 4 >= 4.2.0, PHP 5)
see http://de.php.net/exif_read_data

Andreas.

[cppcodeguru]

Hello Chris,

do you have a solution for this problem?

Thanks,

Andreas.

[Chris Breeze]

I don't think it has anything to do with data being corrupted. I suspect PHP library is expecting an EXIF APP1 block and can't handle XMP APP1 blocks. Photoshop Elements 4.0 is pre IPTC XMP and therefore won't write an XMP APP1 block.

[cppcodeguru]

Hello,

I tested my pictures with the PHP JPEG Metadata Toolkit version 1.11 by Evan Hunter and it could read the information, so I think I am going to use this library, after a few modifications.

Thanks for the support,

Andreas.