PDA

View Full Version : "Exif Print" information in embedded JPEG



molineli
May 17th, 2005, 12:07 AM
It seems that "Exif Print" information in embedded JPEGs from my
10D is missed if "Rotated JPEG" is selected when they
are extracted from RAW files.
Curiously if I extract them without rotating and rotate them after that,
"Exif Print" information is preserved.

Chris Breeze
May 19th, 2005, 07:42 AM
Could you try this again please? When I tested with some 10D raw files from my camera the full EXIF data was stored in the extracted JPEG whether or not the rotate JPEG options was selected.
The only thing I can think of that might cause this is the THM file was missing. BB copies the EXIF data from the THM file and if it is missing it can only write a subset of the shooting data by reading the CIFF data from the CRW file.

molineli
May 21st, 2005, 09:32 AM
In order to check if ExifPrint information is available in a jpeg file,
I try to import it with the "P.I.M. II plugin" (v2.2) provided by Epson
for the Epson Stylus Photo R800. This plugin recognizes both "Print
Image Matching" and ExifPrint information in jpeg files.

I have done next experiment:

I made a new folder with three raw images from my 10D (both -
crw and thm - files for each one). One of them (let's say
"A") shot in landscape format and the others (let's say
"B" and "C") in portrait mode.

Then I did three tests with BB:

For pictures A and B, I extracted embedded JPEG with "Rotate JPEG if required"
and "Store EXIF data in JPEG" options selected.
For picture C, I extracted embedded JPEG with "Store EXIF data in JPEG" option
selected only. Next I rotated C.jpg with BB.

Well, files A.jpg and C.jpg can be imported with the plugin without any problem
because ExifPrint information is recognized, but B.jpg can not.

Chris Breeze
May 23rd, 2005, 04:11 PM
I'm sorry I can't work out why Epson's PIM software isn't recognizing the rotated image. It isn't the EXIF data because you can copy the EXIF data from an image that doesn't work to one that does and is and it still works.

i.e.
"A" is a JPEG extracted and rotated from a portrait CRW
"B" is a JPEG extracted but not rotated from a portrait CRW

Epson's PIM plug-in can import B but not A. If you copy the EXIF from B to A it still can't read A. Copy the EXIF from A to B and it can still read B.

All I can suggest is extracting the JPEG and rotating it as two separate operations if you want to import them using Epson's PIM plug-in.

jonny707
May 23rd, 2005, 06:02 PM
I am posting a reply to this thread because I can't figure out how to start a new thread. My question is that when I extract a jpeg from the canon 10D raw file using BB all the exif information is there when I open it in PSCS but it is showing as "untagged" even though it states srgb in the exif info. How do I tag the extracted jpeg with srgb. The reason I ask is that the extracted image looks much better than the converted image using defaults. Any idea how to apply the same setting to the converted jpeg? I know I can assign the srgb profile but this is an extra step in the workflow.

molineli
May 23rd, 2005, 07:22 PM
Thanks for your attention , Chris!
Could it be that "ExifPrint" information is out of the "Exif section" into jpeg
files?

To jonny707:
I think PS looks for an embedded color profile and do not look at
EXIF data for that purpose. I also guess that if you use PS to save a file
with a different color profile ebedded it does not update EXIF information.

jonny707
May 23rd, 2005, 07:41 PM
Are you saying that the extracted jpeg doesn't have an embedded profile. Is there no way to tag it as such.
I try to keep everything srgb all down the line therefore therefore there is no issue with profiles changing from argb to srgb.

molineli
May 24th, 2005, 06:36 AM
Yes, that is what I mean: JPEGs embedded in raw files are tagged, for example, as sRGB (in EXIF), but they do not really content and embedded profile.
I do not know exactly why, because the profile would spent only a very few kbytes (there must be some technical or legal reason).
Despite this, the fact of files being tagged is important (and useful), so we can know (even in future) which color space should be used to interpret color data.