 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | Rules | You are not logged in.
Pages: 1
I may be beating a dead horse. Sorry if this is actually the case: I could not find a clear answer to my question above after reading numerous threads on different lists or forums on similar topic(s). My concern is about RAW image unexpected rotation and not the same JPEG straight from camera.
I had (almost) never used raw format directly in a stitcher program before. For different compelling reasons I had lately to do so. Having had trouble when inputting .CR2 files in PTGui 9, I have decided to study more thoroughly the problem, but I could not yet find the root cause of the flaw:
http://michel.thoby.free.fr/CR2_orienta … image.html
In fact PTGui 9 and AutoPanoGiga 2.5 seem to be both affected when certain raw images from EOS 5D2 camera are involved. In my test, a simple portrait shot was treated wrongly!
Older versions are not concerned! (if one believes my test results).
Could then dcraw be involved in the root cause of the trouble?
Michel
Offline
I am surprised you managed to get a RAW image to load in the first place.. In fact, the data behind the RAW image would never make a good VR movie anyway.... or perhaps you just want to stitch them.. ether way, its not a good format to use... some of these VR software apps do accept RAW images but they find it hard to interpret all the data.. you will need to filter them... Read this...http://en.wikipedia.org/wiki/Raw_image_format
Some software apps do crazy things with RAW images since they only contain minimally processed data... If you want really high quality images for some reason then use a TIFF.. Normally used for print but they will be as close to a RAW image as you can get making them usable without too many problems... On the other hand, jpg files are highly processed and as a consequence so much of of the RAW data is lost......
Perhaps this is not the answer you were looking for.. D 
Offline
Mr Thoby, as always, you are doing a really in depth reporting when doing something. I cannot answer the why for PtGui, but for Autopano only.
Between v2.0.9 and 2.5 series, only dcraw was updated. The v2.0.9 was already using the camera sensor to be able to get the orientation, so the real difference is reduced to dcraw.
BTW: to confirm that, you could try to use the latest XNView on the same images set. If you got the same behavior ( one wrong image ), it is quite for sure dcraw.
Offline
Note : I talked with P.Gougelet, the author of XNView, he didn't get yet such feedback. But I would like that you try this series to find if it is also in XNView. In that case, we'll report to dcraw directly.
Offline
AlexandreJ wrote:
Mr Thoby, as always, you are doing a really in depth reporting when doing something. I cannot answer the why for PtGui, but for Autopano only.
Between v2.0.9 and 2.5 series, only dcraw was updated. The v2.0.9 was already using the camera sensor to be able to get the orientation, so the real difference is reduced to dcraw.
BTW: to confirm that, you could try to use the latest XNView on the same images set. If you got the same behavior ( one wrong image ), it is quite for sure dcraw.
YES, the problem comes from dcraw. I have got the definitive answer from Erik Krause:
<< dcraw uses the Canon Makernotes "CameraOrientation" flag (which can't be switched off), not the EXIF Orientation (which contains the correct value). I already complained to Dave Coffin.>>
And I have verified his statement:
I had to open Windows XP on the Mac and then run exiftoolgui.exe. "CameraOrientation" is found in the Tag Name column and the rotation in the MakerNotes of the Content column: The value confirms the wrong behavior that we observe!
I could not find "CameraOrientation" in the standard whole "ExifTool" extracted list by only executing a shell in the Terminal of the Mac... I might thus have to learn how to use it better to get the most of it.
Regards,
Michel
Offline
Excellent ! Good find.
Offline
enbilaman wrote:
I had to open Windows XP on the Mac and then run exiftoolgui.exe. "CameraOrientation" is found in the Tag Name column and the rotation in the MakerNotes of the Content column: The value confirms the wrong behavior that we observe!
I could not find "CameraOrientation" in the standard whole "ExifTool" extracted list by only executing a shell in the Terminal of the Mac... I might thus have to learn how to use it better to get the most of it.
Well, the exiftool that was installed on my Mac was obsolete: I have just updated exiftool to 8.46 (Jan. 22, 2011) and it shows all needed metadata.
I apologize to Phil Harvey for my peremptory writing and diffusion of wrong information.
Michel
Offline
Pages: 1
