[Originally posted by igor77 on 2008-11-07 17:16:08-08]
Hallo!
First of all thanks a lot for very useful programs ExifTool and GUI. I am keep on photography and now I try to invent for myself a storage system for my photo archive - and since I have found these programs, this process promise to become easier and more comfortable.
But I can't find how to do batch change of embedded preview in RAW files (canon CR2). I am not programmer, and of course it is easier to use GUI. And I don't find in ExifToolGUI this option. If you can help, I would make a .BAT file to automatize this process, or may be there are prepared solutions of this problem.
The CR2 files and JPG files have the same name except the extension (CR2 and JPG accordingly). There is a lot of .CR2 files in a folder and I need to change embedded JPEG-previews inside all of them. JPEG files are in the same folder or in another one - it doesn't matter.
Please help me with your advice.
Thanks in advance.
[Originally posted by exiftool on 2008-11-07 17:41:37-08]If I understand you correctly, you want to write same-named
JPEG images as the PreviewImage for a set of CR2 files.
This is essentially the same as the 12th example in the
"WRITING EXAMPLES" section of the exiftool application documentation.
For your specific requirements, the command will look more
like this:
exiftool "-previewImage<=JPGDIR/%f.jpg" -ext cr2 CR2DIR
- Phil
[Originally posted by bogdan on 2008-11-07 18:23:32-08]
Hi igor,
Your idea about replacing embedded preview in batch is not new to me -to tell the truth, I myself am very interested on that too.
The problem is not how to implemement this in GUI, but:
When you convert from CR2 to JPG, resulting image is automatically properly oriented: horizontal or vertical. The problem (I have) is: embedded preview must always be horizontal! -and this is the only reason why this option hasn't been made yet.
Preffered scenario would be, JPG images can be used as they come from raw converter (so user wouldn't bother about orientation issue). This implies checking CR2 Orientation tag first, then applying "reverse" (lossless, of course) rotation of JPG, and then embedding image.
Yes, I'm quite sure it can be done... but right now, it seems to be somehow slow for large amount of files -on the other hand, maybe it's better having slow option than no option :-)
Greetings,
Bogdan
PS: Almost forgot... if Phil has any "shortcut" by hand... :-)
[Originally posted by bogdan on 2008-11-07 18:28:51-08]
Hi Phil,
When I was starting writting my previous post, at that time, your post hasn't been there -that shows how slow (english) writter I am :-)
Your example is obvious... how about orientation?
Bogdan
[Originally posted by exiftool on 2008-11-07 21:29:33-08]
The orientation problem is tricky. If the images
are truly rotated (and not just had their Orientation
tag set), then you need an image utility to rotate
them back again. I use jpegtran myself for tasks
like this.
- Phil
[Originally posted by bogdan on 2008-11-08 05:34:30-08]
Hi Phil,
I haven't tried other converters yet, but yes, Canon DPP (which I use mostly) always results properly orientated JPEG files (thus, exif:Orientation is always Horizontal).
I was thinking to use jpegtrans too in this case...
Bogdan
[Originally posted by bogdan on 2008-11-08 14:46:43-08]
Forgot to mention... After embedding image, value of (IFD0) ImageWidth and ImageHeight should be updated too (according to new size JPG might have) -maybe not that important, but some software might expect correct values there.
The more I think, more complicated it appears... I need more time...
Bogdan
[Originally posted by igor77 on 2008-11-09 09:37:31-08]Hi Phil, Bogdan!
Thank you both for quick response and understanding.
Dear Phil, sorry for disturbing with question, which may be described in documentation. It is difficult for me to find such specific information (ExifTool is not trivial program and subject is not simple too), and I'm not very good in English. Unfortunately after trying command you've suggested, I receive next message in Windows:
K:\ExifTOOL\2>exiftool "-previewImage<=JPGDIR/f.jpg" -ext cr2 CR2DIR
Error opening file JPGDIR/f.jpg
Nothing to do.
And after that there are no changes in CR2 files.
Dear Bogdan, I agree with you, that "it's better having slow option than no option" ;-) I think so especially like user ;-)
I use DPP as well, and I think that it is very big disadvantage of this program that it doesn't replace preview after processing.
About orientation. Of course I'm not specialist, but is it possible to compare width and height of JPEG and to match this information with orientation tag? As I understand, in camera image is 'horizontal' when width is more than height. May be there are many unusual situations when orientation tag not correspond to width/height correlation, but I think it can be checked.
Dear friends, what is 'jpegtrans'?
Igor
[Originally posted by exiftool on 2008-11-09 12:08:20-08]
Hi Igor. Just to be clear, you did replace JPGDIR and
CR2DIR with the actual directory names on your system?
jpegtran is a command-line program for manpulating
JPEG images, and it will do lossless rotation. -Phil
[Originally posted by bogdan on 2008-11-09 12:55:41-08]
Hi Igor,
Yes, one can determine vertical/horizontal image by "if width is smaller than height". But, by doing it that way, we can't determine in which direction vertical image must be rotated (left or right).
The problem is, not every photographer hold camera (when taking vertical shots) the same way (and all the time). Me personally, when taking portrait shot, I always hold camera with shutter button being on top (I believe, that's how camera must be held for portrait shot) -but I can't just assume everybody does the same way.
Anyway, I'm working on that right now... have some troubles understanding how exiftool works, though :-)
Greetings,
Bogdan
[Originally posted by igor77 on 2008-11-10 07:12:44-08]
Hi, Phil, Bogdan!
Dear Phil, of course I didn't replace :-) I thought JPGDIR and CR2DIR were parameters of command. I've only put all files and ExifTool in one directory. I'll try again tonight at home, now at work I haven't RAWs. Thanks a lot!
Dear Bogdan, you are perfectly right! I didn't think about it. For instance, I usual hold camera verticaly when right hand is on top, but very rarely I hold it left on top. My wife always holds it left hand on top. And it is interesting, that camera always knows how to rotate image. That's why I suppose (I don't know subject as well as you do, I only can suppose) that there is a tag in RAW, which tells how rotate image. And if you replace this tag, it doesn't matter, how JPEG 'lies' inside RAW - top on right or top on left. If you know, that JPEG is vertical, you rotate it (to any side) and write about sense of rotation in RAW tag.
If tag already exists in RAW....
...Hum... I have next idea. Orientation of RAW and embedded JPEG must be the same. If there is no information in RAW file about orientation, and JPEG is vertical, it is real problem. And I really don't know how to solve this problem correctly. If there is no information in RAW and JPEG is horizontal, we can embed it 'as is'. If there is information in RAW about orientation, and JPEG is vertical, we can determine where must be top and rotate JPEG correctly. If JPEG is already horizontal, I think it is no need to do any rotation.
Of course, it is only my supposition. May be it is better for me to not impede and to wait the result from you :-) In any case I'm ready to test your program when you finish.
Best regards,
Igor
[Originally posted by igor77 on 2008-11-10 08:09:57-08]
Dear Bogdan!
I,ve just observed on your question, where you work with orientation tag of JPEG. I look through my JPEGs and I see, that ALL of them have tag 'horizontal' - even images, which are vertical in fact. I do not know what this tag means in JPEG, and whether such programs as DPP, AcDsee, FastStone etc use this tag while they produce images, but it is fact that in all my JPEGs this tag is the same.
Igor
[Originally posted by bogdan on 2008-11-10 16:52:21-08]
Hi Igor,
Btw. I'm glad you get somehow involved in this stuff :-)
Yes, inside CR2 file, actual orientation of embedded JPG file and actual orientation of raw image data is always the same: horizontal (no matter how camera was held).
When DPP opens raw, it reads Exif:Orientation value, rotates raw image data if needed, and displays image horizotally (no rotation was applied) or vertically. Thus, if you see vertical (CR2!) image inside DPP, you must know, it was rotated on-the-fly (just for you).
When you convert to JPG/TIFF, then DPP always rotates image to needed orientation, and set Exif:Orintation tag inside resulting JPG to Horizontal -meaning: software, which opens this image (some image viewer), doesn't need to do any rotation before displaying.
Now, if I understand your idea, I could embedd JPG into CR2, as it is, and only change Exif:Orientation tag (inside CR2) according to new embedded image orientation?
This doesn't work, I've tried (see above: When DPP opens raw) -DPP shows vertical images horizontally.
In short: embedded JPG must have horizontal orientation (having width greater than height), and Exif:Orientation value (inside CR2) shouldn't be changed. So, before embedding, JPG must be rotated (if needed). It's only, from where this info (in which direction to rotate) can be obtained -and I believe, the simplest way is to read Orientation from source (CR2) file, and do reverse rotation.
Yes, JPG's comming from DPP, do always have Orientation value Horizontal -this just tells the software (DPP, ACDSee,...) image shouldn't be rotated (because it allready has proper orientation) when displayed.
Yes, 99% of all software reads Orientation tag value before displaying image. Well, Windows Fax and Image viewer isn't among them, but still displays vertical JPG images (from DPP) correctly -because (as said), DPP has already done proper rotation.
I hope, I helped you clarify some things... and, at the same time, all above helps me, not to forget something :-)
Bogdan
PS: Sorry, if I've repeated me too much... as engilsh isn't my native language, and I want to be sure, I made myself clear.
[Originally posted by igor77 on 2008-11-11 09:47:32-08]
Hi, Bogdan!
Thanks for explanation. I've already understood it when I wrote my previous post. To change orientation tag in RAW is wrong way. May be more productive idea was the second one.
First of all I suppose, there can be cases when there is no information about orientation in RAW tags. May be it is incorrect opinion, but still. In this case if JPEG is already horizontal, we can embed it 'as is'. If JPEG is not horizontal - it's like a lottery. We can rotate it to make horizontal, but can't be sure, if it is correct. Result can be rotated to 180 degree relatively to RAW position.
Next, DPP as you say, always make properly orientated image with 'horizontal' tag. But JPEG can be made by another program and this tag can be important. In theory it can be big mess in tags, width/height and the real orientation. We need to find the real orientation of JPEG and do reverse rotation according to CR2 tag.
We have to make the assumption that (1) JPEG which we want to embed is properly oriented (when we look on it in a viewer) OR (2) it has the orientation like RAW has (we can convert RAW without implementation of rotation) - it looks like vertical image lies sideways.
In the second case (if JPEG have to be seen vertical - height more than width - but it is horizontal in fact) we embed it 'as is'.
Well. I try to prepare algorithm.
1. Compare width/height of JPEG. If width>height than we have value '2' (horizontal). If width<height than we have value '1' (vertical). It may be other values - it is important only for calculation, see step #2.
2. Next look at the orientation tag of JPEG. When we see the image in the viewer, we see it with applied tag.
We have value '3' if image rotates 180 degree CW, '1' for 0 degree, '6' for 90 degree and '8' for 270 degree. May be it can be another functional dependence, but we can see that for even number we change orientation, and for odd value we have the same orientation, but may be rotate it upside down.
3. Then we sum up value from step 1 and step 2.
If result is even number (1+1 or 1+3 or 2+6 or 2+8) - we will see in viewer vertical image.
If result is odd (2+1 or 2+3 or 1+6 or 1+8) - it is horizontal image.
We have to remember about mentioned assumptions.
We need only information 'vertical' or 'horizontal' and we have it.
Now we have the position of JPEG, which we can see in a viewer.
4. Look at the orientation tag in RAW.
4.1. If it is '1' (90 degree) or '3' (270 degree) - image is vertical.
4.1.1. But if in the step #3 we have 'horizontal' - we embed JPEG 'as is' (look assumption #2). To be honest, we have to apply JPEG rotation (tag in step #2), because we work with final view of the image in a viewer.
4.1.2. If in step #3 we have 'vertical' - all is Ok - we make reverse rotation and embed received JPEG. It is important that we must have in view JPEG rotation (tag in step #2).
4.2. If it is '0' and in the step #3 we have 'horizontal' - we embed JPEG 'as is'. If in this case JPEG is vertical - it is incorrect. May be it is situation "no information about orientation in RAW tags" mentioned above.
May be it is not complete logic, but may be it can help. Two heads are better than one :-)
But... there is a little problem if JPEG is croped image with changed orientation. For instance, vertical portrait croped from horizontal image. Well, it is impossible to predict all situations :-)
Best Regards,
Igor
P.S. About language. Bogdan, I understand you very well. I guess, you are Russian-speaking :-) We have the same way of thinking.
[Originally posted by bogdan on 2008-11-11 15:39:00-08]
Hi Igor,
I see, you've done homework :-) The thing, we agree on, there are many posibilities (plus guessing involved) -not to mention crop issue, which I didn't think of yet.
Because of that, inside GUI, there won't (can't) be every possible situation taken into account -in special cases, user would need to rotate images (before embedding) as needed. No big deal, I think.
Anyway, I'll try to support workflow as from DPP in first place, because of many reasons, e.g:
-it's Canon's official (and free) software,
-it's the only converter, which preserves all metadata (exif+makernotes,iptc and xmp) when converting to JPG/TIFF,
-after all, we are embedding something into Canon original file!
-and finally: DPP is my favourite converter :-)
I'm quite sure, it will work for most normal cases. Now, where do I get time to do something?..
Greetings from Slovenia,
Bogdan
[Originally posted by igor77 on 2008-11-12 08:55:19-08]
Hi, Bogdan!
I am happy that you want to do it and you have ability to realize it. My knowledges are not enough :-) I agree with you at all.
Good luck! I'm looking forward to good news ;-)
Igor
P.S. I think Russia and Slovenia (and Ukraine, and etc.) have Slavonic languages with similar structure. And I supposed Bogdan as Ukrainian name. That's why I surmised you were from Ukraine. ;-) Best wishes to Slovenia!
[Originally posted by igor77 on 2009-01-07 09:56:56-08]
Hi, Bogdan!
I found a new version of you GUI some time ago and only now I've tested new function "embed previews to CR2" on group of files.
All works well, thanks a lot for your work. But there is one bug.
As I see, after converting via DPP all JPEGs have horizontal orientation, even if their actual orientation is vertical. It is not problem - your program checks orientation well.
The main problem is when we rotate image in DPP.
When in camera I set flag "rotate on PC screen" - all RAWs have in EXIF information about vertical orientation (camera writes it). In this case I can see RAW in all viewers correctly oriented. After DPP convertion to JPEG we have correctly oriented images too.
But, if I rotate image in DPP, orientation tag (which I can see in GUI) stays horisontal (or vertical). It does not change! We have to rotate images sometimes, especially if in camera we set "do not rotate".
After such rotation, I see image rotated in DPP, but it is not rotated in other viewers! I don't understand, where DPP writes information about rotation.
That's why we receive after DPP correctly oriented JPEG, but RAW is not rotated. We can not embed such JPEG in RAW, because in other viewers and cataloging programs we will see RAW incorrect.
May be it is bug of DPP? I use 3.5.1. version.
All the best!
Igor.
[Originally posted by igor77 on 2009-01-28 18:01:57-08]
Hi, Bogdan!
I found a new version of you GUI some time ago and only in January I've tested new function "embed previews to CR2" on group of files.
All works well, thanks a lot for your work. But there is one problem.
As I see, after converting via DPP all JPEGs have horizontal orientation, even if their actual orientation is vertical. It is not problem - your program checks orientation well.
The main problem is when we rotate image in DPP.
When in camera I set flag "rotate on PC screen" - all RAWs have in EXIF information about vertical orientation (camera writes it). In this case I can see RAW in all viewers correctly oriented. After DPP convertion to JPEG we have correctly oriented images too.
But, if I rotate image in DPP, orientation tag (which I can see in GUI) stays horisontal (or vertical). It does not change! We have to rotate images in DPP sometimes, especially if in camera we set "do not rotate".
After such rotation, I see image rotated in DPP, but it is not rotated in other viewers! I don't understand, where DPP writes information about rotation.
That's why we receive after DPP correctly oriented JPEG, but RAW is not rotated. We can not embed such JPEG in RAW, because in other viewers and cataloging programs we will see RAW incorrect.
May be it is bug of DPP? I use 3.5.1. version.
All the best!
Igor.
[Originally posted by bogdan on 2009-01-28 20:10:50-08]
Hi Igor,
No, there isn't a bug in DPP. Now, short insight -I hope my english won't let me down :-)
Image file directly from (EOS) camera, contains two image orientation tags inside Exif: one is inside IFD0 section (as expected by most image tools), another is inside Makernotes section. It is worth to note, that not neccessary both contain the same value (depends on camera setting)
Now, if you rotate CR2 image inside DPP (and save), both existing orientation tags remain unchanged -and a third one is added into CanonVRD section (note: CanonVRD section doesn't exist in original CR2 file -it is added by DPP).
So far: no matter what camera (orientation) settings you used and regardless of rotations applied inside DPP, actual image orientation is allways the same: horizontal.
As we (can) deal with three different orientation tags (and values), which one shoud be used by default?
1. By most software, "classic" Exif Orientation tag is used (if at all).
2. Tag inside Makernotes tells how camera really was oriented (regardless of settings).
3. Tag inside CanonVRD just tells (to DPP only!), that you've "changed your mind" later (about orientation).
I've tried to make (automated) embedding images as simple as possible. But if you change orientation (later) inside DPP... -no software (except DPP) cares about that. Also keep in mind, that DPP doesn't use/show embedded image at all.
My advice (finally): don't rotate inside DPP (use camera setting). If you really need to rotate image afterwards, then embedding images in batch (using GUI) is very difficult as it requires additional physical (manual) rotation of each image (before embedding) and probably changing IFD0:Orientation tag value as well. But this can lead to things you've allready observed: DPP shows correct orientation but no other software does (and/or opposite).
I hope this was of some help...
Greetings,
Bogdan
[Originally posted by igor77 on 2009-01-29 10:06:14-08]Hi Bogdan!
Thanks for detailed description. You give real help.
It is terrible that we have 3 places to keep information about orientation! Now I understand why Adobe promotes the DNG format

But I am not ready to switch to the DNG and still hope to optimize workflow with CR2 files.
You have told about CanonVRD section. Can Exiftool see this section? If yes, it will be usefull to sinchronize all information. If no - of course it can be manual work only.
Of course, it will be better to introduce all this things inside DPP. But I doubt that Canon will do it.
May be it will be usefull to add in GUI the function of manual embedding, when we can see both CR2 and JPEG and can decide how to rotate image. But it can be labour intensive.
Anyway, thanks a lot.
All the best,
Igor
[Originally posted by bogdan on 2009-01-29 16:07:46-08]
Hi Igor,
Three orientation places can be confusing at first sight... but I see there's a logic behind:
1. Average user (& 3rd party software) should read IFD0:Orientation and everything should be fine -and usually is.
2. Makernotes:Orientation just tell how was camera actually held -regardless of settings.
3. CanonVRD:Rotation is DPP's internal tag -3rd party shouldn't care about it.
Looking at things that way, DNG doesn't offer more (in regard of your issue), IMO. If it does on some areas, then only as long you're using Adobe software. Now you decide :-)
Of course Exiftool knows about CanonVRD -otherwise, GUI couldn't know about this section :-) Inside GUI, you can see this section by choosing Maker button (tags will be listed at the end of the list).
Right now, I don't think about changing something in regard of embedding previews. As you've noticed, there's complicated logic involved -on the other hand, I'm trying to keep GUI simple (and as fast as possible).
For special cases, I advice everyone to use Exiftool directly (by making custom scripts).
If I can express a wish about DPP: would be nice, if DPP would allow to embedd image back to CR2 (where current DPP settings would be used for conversion); meaning: instead of converting to JPG file(s), resulting JPG image would be embedded back into CR2. Now, let us pray...
Best wishes,
Bogdan
[Originally posted by joseph001 on 2009-01-30 08:11:53-08]HI friends,
This is Joseph.
I am new to this forum. I don't know much about this forum.
When my friends told me about this then I saw it.
Joseph
Make Money
[Originally posted by igor77 on 2009-02-18 07:13:57-08]
Hi!
Dear Bogdan, or Phil, or anybody else. May be you can help me with the syntax of .BAT file to copy (and replace) CanonVRD:Rotation tags values to the IFD0:Orientation tags in all .CR2 files in a folder.
Thanks in advance.
Igor.
[Originally posted by igor77 on 2009-02-22 19:24:56-08]Hi!
Dear Bogdan!
You helped me clarify many things. Now I understand that many my questions above were stupid.
I suppose I've understood the main thing. If we use DPP as a main RAW-converter, the algorithm of change of embedded preview is more simple than I've thought.
As you've written, DPP uses CanonVRD section of CR2 file to orient image. But when CanonVRD:rotation tag is empty, DPP looks to the EXIF:orientation tag.
If in EXIF we have proper information - we have no need to rotate image and all is Ok.
When we do write new recipe to the CR2 file, even if we do not rotate image, DPP writes "0" to CanonVRD:rotation (it is empty before saving recipe).
When we rotate image in DPP, it writes new value to this tag and in future DPP ignores EXIF:orientation.
I do not know about all users, but I think it is normal to rotate RAW correctly while processing in RAW converter. That's why we have properly oriented image in DPP.
After converting we have JPEG which is the same oriented as CR2 in DPP (tags are different, of course).
Here is the
main idea. If we do not rotate images
after converting (I think it is natural - we have not to do it), orientations of JPEG and CR2 are equal.
In all cases it is very simple to convert CR2 to JPEG in DPP and to change embedded preview in Exiftool at once.
That's why we do not need to think about JPEG orientation - we only need to do reverse rotation relatively CR2 rotation in DPP.
We look to CanonVRD:rotation tag (
not EXIF:orientation) in CR2 and rotate JPEG backwards.
I wrote earlier about my problem with GUI when I embed new previews in images, which were rotated in DPP. I solved this problem.
I've just synchronized CanonVRD:rotation tag with EXIF:orientation tag with the comands:
exiftool -s -n -if "$CanonVRD:rotation eq 0" -exif:orientation=1 *.cr2
exiftool -s -n -if "$CanonVRD:rotation eq 1" -exif:orientation=6 *.cr2
exiftool -s -n -if "$CanonVRD:rotation eq 2" -exif:orientation=3 *.cr2
exiftool -s -n -if "$CanonVRD:rotation eq 3" -exif:orientation=8 *.cr2
After this I have no problem to use GUI and different viewers. All of them shows CR2 images properly. When I embed previews in GUI, I use only automatic mode.
I do not need to think about how I hold camera - right hand on top or left one. All works in automatic mode.
I might use Exiftool without GUI to whole process, but my knowledges are not enough to write all comands in command file.
That's why I have to do two steps: execute .bat file and next use GUI.
Also I find the second problem.
In a CR2 file I find the second preview - very small thumbnail JPEG (160x120 pixel in Canon 400D) and some viewers use this preview while looking images as thumbnails.
We can see this thumb in ThumbnailImage tag. This viewers are, for instance FastStone viewer 3.2. and Adobe Lightroom 2.0.
With Lightroom it is more interesting

First it shows thumbnails, next it changes thumbs to resized JPEG previews (size like thumbs), and finaly it shows CR2 file (it takes more time).
So we can see all three images in one CR2

Thus, problem is that if we change preview, it will be correct to change thumbnails also. It is as oriented as embedded JPEG preview.
So we can resize rotated JPEGs and embed they as thumbs. I do not know now how to realize this and if there are other tags linked with thumbs, but still.
Sorry for many characters - I'm not good in English.
I hope, my ideas can be usefull.
Best wishes,
Igor.
[Originally posted by igor77 on 2009-03-05 12:02:25-08]Hi, Bogdan,
To continue the theme started in previous post.
I have tested this algorithm in different cases and it works. And rotation in DPP is not a problem.
I'm not programmer and this BAT file (for Windows) may be not fine, but it works. I've wrote some remarks in the text.
@ echo off
rem 1. put in the folder with CR2 files the folder JPG with jpeg-files obtained after DPP
rem convertation. The names of JPEG-files must be the same with CR2-files.
rem 2. in the same folder put this BAT-file, Exiftool.exe and nConvert.exe
rem (http://www.xnview.com/en/nconvert.html)
rem 3. run BAT-file.
echo ****************** synchronization of EXIF and CanonVRD ********************
rem Synchronization of orientation tags in CR2 files with giving preference
rem to DPP processing. DPP looks on CanonVRD:rotation tag at first.
rem If CanonVRD is not empty, we change in *.cr2 files the value of
rem the tag "exif:orientation" accordingly to the value of the tag "CanonVRD:rotation"
rem If CanonVRD:rotation tag is empty, DPP looks on EXIF anyway - this case
rem we have no need to do something.
exiftool -overwrite_original -s -n -if "$CanonVRD:rotation eq 0" -exif:orientation=1 *.cr2
exiftool -overwrite_original -s -n -if "$CanonVRD:rotation eq 1" -exif:orientation=6 *.cr2
exiftool -overwrite_original -s -n -if "$CanonVRD:rotation eq 2" -exif:orientation=3 *.cr2
exiftool -overwrite_original -s -n -if "$CanonVRD:rotation eq 3" -exif:orientation=8 *.cr2
echo *************************** rotate JPEG to 360 degree ********************
rem After previous section we have either EXIF orientation tag, which is
rem synchronised with CanonVRD, or CanonVRD is empty and Exif is dominating.
rem If EXIF:orientation is empty or equal 1, we have no need to rotate anything.
rem Rotate accordingly to EXIF tag:
rem 1 - 0 degree rotation. We do not rotate
rem 6 - 90 degree rotation CW. We rotate JPEG 270 CW
rem 3 - 180 CW. We rotate JPEG 180 CW
rem 8 - 270 CW. We rotate JPEG 90 CW
rem We use nconvert.exe for rotation, because it rotates not only JPEG itself,
rem but the ThumbNail inside JPEG too. It is just what we need.
rem Unfortunately the program Jpegtran kills thumbnails.
for %%i in (JPG\*.jpg) do (
for /F "DELIMS==" %%k IN ('exiftool -n -s -s -s -exif:orientation %%~ni.cr2') DO (
if %%k==6 (nconvert.exe -jpegtrans rot270 JPG\%%~ni.jpg)
if %%k==3 (nconvert.exe -jpegtrans rot180 JPG\%%~ni.jpg)
if %%k==8 (nconvert.exe -jpegtrans rot90 JPG\%%~ni.jpg)
)
)
echo *****************************renew Width tag ******************************
rem It was detected that in CR2 file tags Width and Height allways have
rem horizontal arrangement. That's why we must renew these tags after
rem properly orientation of JPG files. nConvert does renew these tags after
rem rotation. We may just copy them.
exiftool -overwrite_original -b -tagsfromfile JPG\%%f.jpg "-ImageWidth<$ExifImageWidth" *.cr2
echo ***************************** renew Height tag ******************************
exiftool -overwrite_original -b -tagsfromfile JPG\%%f.jpg "-ImageHeight<$ExifImageHeight" *.cr2
echo ****************************** change thumbnail ***********************************
rem It was detected that processing in Exiftool takes more time if file lenght is bigger.
rem That's why we move operations which makes file bigger to the end of processing.
rem We change in CR2 files thumbnails and previews to the new one which we take from JPEG-files.
rem DPP allways saves thumbnails. If we do resize JPEG images before embedding, we have to be
rem sure that thumbnails are conserved. For instance we can use FastStone for resize (www.faststone.org)
rem or mentioned nConvert.exe
exiftool -overwrite_original -b -tagsfromfile JPG\%%f.jpg "-ThumbnailImage<$ThumbnailImage" *.cr2
echo ****************************** change preview ***********************************
exiftool -overwrite_original -b "-PreviewImage<=JPG\%%f.jpg" *.cr2
echo
echo ****************************** the end *****************************************
pause
I have tested this BAT and do not find mistakes yet. Thumbnails, Preview images, RAW data are visible in different programs. May be it will be usefull for you or you will be so kind to give some advice.
Best wishes,
Igor.
[Originally posted by bogdan on 2009-03-05 20:55:28-08]
Hi Igor,
I've somehow lost the track of this thread... so I've read it completelly again -as I have a feeling, I tend to repeat things :-).
To your batch file first. I didn't go thru it line by line, but it does makes sense... so, I've copied it and tried. Haven't tried all possible combinations, but in case you rotate (inside DPP) Horizontal taken image to the right and convert, then above batch has problems (it runs in endless loop) -but that can be solved, though.
Now, what I did (again)... I took two CR2 examples: one horizontal and one vertikal taken photo. I've opened those two inside DPP, where I rotated both in right direction and converted to JPG.
Then I've made a simple (big) "signature" on both JPG images (using Corel PSP), so I can easy identify them as "edited preview". Now, using GUI, I imported both jpg images back into CR2.
When doing this, GUI alerted me (with reason), that one of both has "wrong" orientation. Because I knew, this has nothing to do with actual camera orientation (it was DPP), I didn't choosed "Rotate now" button. I just clicked on "Embed" button (meaning: let GUI decide what to do).
And it did as expected: when using viewer (fastone), CR2 orientation is the same as when seen inside DPP -and that was the goal, IMO.
Of course, when you again extract jpg preview from CR2 (without exif data), then orientation of extracted jpg will be wrong -that's why I've made menu "Options>Copy Exif when extract JPG from CR2".
As said, I didn't go thru all possible combinations, still I believe, in general, GUI does what I was trying to accomplish.
Thumbnail issue... To be honest, the only tool (I know of) which uses thumbnails inside CR2, is IrfanView. I would bother (after all, IrfanView is well known), but after changing jpg preview inside CR2, IrfanView has some troubles showing thumbnail anyway (all I could see, was "black" thumbnail).
The thing is (as I see it), today's PC's are very fast and can show previews as thumbnails on the fly -I've never missed thumbnails, so to speak.
Back to your solution. Yes, I agree, the way you think of, is probably most complete (when finished). The problem I see, is speed: for each image, exiftool and nconvert are called several times...
There's another thing you probably didn't notice: if jpg image (you wish to import) contains metadata, then complete metadata will be again imported into CR2 file. Meaning, added metadata resides (as duplicate) inside jpg preview section -just takes space, though.
That's it. Anyway, I see you didn't give up on this. That's good, really -just keep on.
Greetings,
Bogdan
[Originally posted by igor77 on 2009-03-06 09:59:00-08]
Hi, Bogdan,
Of course I didn't give up :-) I try to keep only CR2 files on PC and to refuse keeping JPEGs. It will be like DNG file. Because I mostly use DPP to convert CR2, and I use different programs for viewing, cataloging etc., I try to look on CR2 and JPEGs like DPP looks, and I try to make other applications to do the same. That's why I use CanonVRD tags as paramount, and even copy them to the exif. I've allready sent message to Canon with the offer to introduce this function to DPP.
About slow processing - I think it is not a problem, because this option is not a part of quick workflow. By the way, converting CR2 to JPG is not fast too. As for me after processing in DPP I can start converting and do other work. The same way after receiving JPEGs I can start embedding and drink some coffee ;-)
About thumbnails: Abobe Lightroom can see thumbnails. I've allready written, that at first LR shows thumbnails, next it changes thumbs to resized JPEG previews (size like thumbs), and finaly it shows CR2 file (it takes more time). So we can see all three images in one CR2. I'll have look on IrfanView. Nevertheless I suppose if we change preview it must be universal CR2 file.
I didn't think about metadata incide JPEGs I wish to embed. To be honest, I didn't know that Exiftool embed JPEGs with whole metadata. I'll think about it. May be it is not so bad. Otherwise in future we must copy exif to extracted from CR2 JPEGs. On the other hand, it is superfluous data...
I have not possibility to check your variant with batch file now - I'll do it at weekends. I see only one place where endless loop may take place. It is "for" operation. In other places cycles are generated by Exiftool. And the cause may be only in syntax or logic. I'll have a look.
But still... Lets look by steps your example.
A) We have two images:
- 1.CR2 - horizontal - EXIF:rotation=1
- 2.CR2 - vertical - EXIF:rotation=8 or 6, or 1 (if camera do not write orientation to EXIF)
B) We rotate them in DPP 90 degree CW. We have:
- 1.CR2 - now vertical in DPP - EXIF:orientation=1, CanonVRD:rotation=1
- 2.CR2 - now horizontal in DPP - EXIF:orientation=8 or 6, or 1, CanonVRD:rotation=0, or 2, or 1 accordingly.
C) After converting we have:
- 1.jpg - vertical
- 2.jpg - gorizontal
D) Now what will you do next? I try to understand your logic to check and correct mine.
IMO the goal is to embed JPEG acordingly to RAW-data. Not only to see in a viewer the same look as in the DPP. If we do not change EXIF in compliance with CanonVRD, Faststone does not have to show the same picture. It must show the same aligned picture as it was before change preview.
I understand that we can have a bit different approaches - that's why your logic is important for me.
Best regards,
Igor
[Originally posted by bogdan on 2009-03-06 11:26:40-08]
Hi,
No Replay(+quote) option in this forum... but I'm very sure we understand each other.
Lightroom thumbnails: yes, I believe you. But, on my average PC (Intel E8200) I can hardly notice that (must happen for very short time).
I'm with you, when you say, all parameters (thus, incl. thumbnail) should be updated as well. On the other hand (to keep that word), then you should embed new (modified) thumbnal instead of existing one.
And to make things worse, there might be two different thumbnails inside CR2 file:
1. 160x120 "thumbnail of CR2" -this is "main" thumbnail, so to speak.
2. 168x112 "thumbnail of JPG" -which is embedded into preview (jpg) image.
I said, there "might be", because newer EOS cameras (5Dmk2, for example), doesn't have that second thumbnail at all. For reasons like this, I gave up on thumbnails.
Viewing CR2 (in Faststone, etc.)... There are two basic options:
1. Viewing actual raw image (converted by Fastone),
2. Viewing embedded jpg image
-in both cases, only Exif:Orientation tag is used for correct orientation. DPP does opposite: it only uses CanonVRD tag. And RAW-data remains unchaged all the time anyway. I don't see any troubles here (I mean, the way GUI does that).
Of course, it can happen, GUI may not embed image with orientation expected by user. But I see those as special cases -GUI is ment, well... for "everyday" use :-)
As for special cases: they can be solved only when using exifool "pure" :-)
I don't think our approaches differ much. I'm trying to make "best possible" too, as long "I see" it's worth to bother -and there's enough time to do it.
Greetings,
Bogdan
[Originally posted by igor77 on 2009-03-06 14:06:05-08]Hi!
I'll try to answer by steps
> then you should embed new (modified) thumbnal instead of existing one.And I do it - I use thumbnail from new jpeg, which is similar to the big jpeg file. And moreover it has proper orientation after rotation jpeg file by nConvert.
> two different thumbnails inside CR2 fileTo be honest, I can't find second preview which is embedded into preview (jpg) image. It exists there after changing preview (with whole metadata), but if I extract embedded preview from initial file (just from camera) - I can't find preview there.
Also I know about 160x120 thumbnail of CR2, and 168x112 thumbnail of JPG, but I find the second preview only in JPEG which I receive from DPP. And after embedding this 168x112 thumbnail to CR2 I didn't find any problems in other programs, in spite of different size.
> DPP does opposite: it only uses CanonVRD tagNot "only". Yes, it uses CanonVRD to write, but to read (and show image correctly) it uses also EXIF information if CanonVRD is empty. If we save "receipt" to the CR2 file, even if we do not rotate image in DPP, it writes to CanonVRD:rotation tag the value according to EXIF information. It always writes rotation tag according to how we see image on screen - if we do not rotate image in DPP, it writes just EXIF value. And the next time it use already CanonVRD tag.
Of course I agree about using only EXIF information by other viewers.
I think we may segregate this issue into three cases:
1. If we use only DPP to converting. This case we have to look to CanonVRD tags and if they are empty - to EXIF. I am still sure that this is correct algorithm.
2. If we use another converter. Here we have to look to EXIF and sometimes to additional XMP-file (after Adobe converters).
Both this cases (1 and 2) it is important that we must not rotate images after converting. So we may be sure about proper orientation.
3. If we do rotate images after converting and in all other cases we may only guess how to lay down vertical JPEG, or we may tell to program, how was camera oriented - like you have realized in GUI.
I suppose, for universal use you may ask user additional question

Best regards,
Igor
[Originally posted by bogdan on 2009-03-06 16:31:53-08]
Hi Igor,
You're right about thumbnails. After "playing" with embedded previews (horizontal, vertical, with and without metadata), I've picked CR2 file of which embedded jpg was already replaced (that's why I said newer cameras don't have them -this time original was used). That is, only one thumbnail exist inside CR2.
Sorry for confussion... but these things happen when messing with metadata, etc. :-)
Yes, the first time (no CanonVRD present) DPP looks into Exif:Orientation (as for "starting point" so to speak), but after CanonVRD is written, Exif:Orientation isn't used anymore -even if we change Exif:Orientation afterwars, DPP will keep previous orientation. I see nothing we don't agree on here :-)
I've implemented embedding option into GUI having in mind:
1. User would like to see (from preview) his final work (no matter what converter being used). For very first time he may use DPP (for example), later he can change his mind and embed image produced by ACR. Does now embedded image reflect DPP's settings? No.
2. Embedded preview is just one of developed images we can get from raw. As example, I don't use DPP's noise reduction for hi-ISO images. I export TIF (no noise reduction, no sharpening), then I use another software for further editing... and embed result back to CR2.
What I'm trying to say is: I'm changing preview, only to have some "default" developed preview (ready for 6x4" print, if needed). And that's what I ment by "everyday" use.
And as said, I'm aware, that my way of thinking, doesn't neccessary suit everybody needs. This is where you can help by finding different/better solutions and sharing them.
Your procedure (the way of thinking) seems to be ok. But (from my experience), one can never be 100% sure :-) Why don't you make a "package", so other could download it? This way, you would get feedback about usability and possible improvements (and bugs eventually).
Enjoy the weekend,
Bogdan
PS: If you do freeware, don't ask users what they want (believe me, you don't have enough time for that) -they will make their wishes anyway :-)
[Originally posted by igor77 on 2009-03-10 07:54:29-07]Hi, Bogdan,
First about my batch file. I tried it with different situations, also I tried the variant as you said (rotate (inside DPP) Horizontal taken image to the right and convert), but I didn't find any troubles. There was no endless loop, all worked correctly. It is strange...
I absolutely agree with your reasoning.
>one can never be 100% sureYou are quite right :-) That's why I am happy to discuss this issue with you. Two heads better than one.
>Why don't you make a "package"...I'll think about it :-) But, as I have said, I'm not a programmer, and I'm not sure that my batch is good and safe. I've received at least one feedback from you - and I'm very glad about that ;-)
>they will make their wishes anywaySometimes user's wishes are very useful. Public discussing can improve software very much. The main problem, as you've said, is time. I'm very surprised of Phil - he answers every question on this forum! It is strikingly, and deep respect to him!
I hope, you do not look on our discussion like on "just a wish" ;-) After all I try to realize my own way, not to make you to do it.
By the way... I've already asked Phil about the order of different tags (
http://www.cpanforum.com/threads/10112) and I see that these changes are not important. But I find interesting thing. When I change thumbnails, previews and other tags in different combinations, in all cases the tag "ThumbnailOffset" saves it's value (thumbnail saves it's position in CR2 file). But when I use GUI, this thumbnail moves to the beginning of the file on 430 bytes. I tried it many times, but standard it is 430 bytes.
Best wishes,
Igor
[Originally posted by igor77 on 2009-03-10 15:56:53-07]
Hi, Bogdan,
I tried your example in the post 10119 in GUI. You know... it works only as you have said - CR2 in FastStone looks as in DPP. But inside... JPG preview has even vertical (!) orientation. I extract it after embedding and it is vertical.
Moreover, I suppose FastStone can see thumbnails. As a result when I see CR2 in FastStone in the main window I can see thumbnails and preview. Here I can see the confusion with orientation of previews and thumbnails.
I think after rotate in DPP we can not use GUI to embed new preview to avoid confusion. We can use it only after synchronization of orientation tags as I wrote in the post 9830.
Best regards,
Igor