Jump to content

Recommended Posts

I'm currently testing the X100V as a possible sensor for aerial image capture for photogrammetry purposes. For such applications, knowing the image orientation is critical and so normal practice involves disabling any on-camera auto image rotation.

Cameras usually handle auto image rotation in two parts:

  1. Detection of camera orientation during capture, which determines what is written to the EXIF information; and
  2. Detection of camera orientation during viewing, which determines what is displayed (based on the file EXIF information).

The first part determines what value is written to the image file's EXIF orientation flag (documented in various references). However, what these references don't mention is that the orientation also ends up affecting the image width and height, which are also written into the EXIF information. While the orientation flag can be modified using various tools (or settings on cameras or software packages) so that the images can be viewed in whatever orientation is desired, the image width and height do not change.

So, why does this matter for photogrammetry? Well, a key aspect of the process involves determining intrinsic camera parameters that are expected to be identical for all images in the set. One of these parameters is the image size, so we need the width and height to be the same for all images! When a camera decides to randomly go and write different values for the width and height depending on how the camera is oriented (something that's hard to control in aerial capture), that becomes a big problem.

I use a Nikon D850 for a lot of my work and that camera provides the ability to properly disable auto image rotation, i.e. the camera writes exactly the same EXIF information for orientation, image height and image width no matter how I hold the camera. The Sony mirrorless cameras I've tested, on the other hand, don't seem to provide that same capability. Now, in testing the X100V, I'm concerned that I may be facing the same problem.

From what I understand of the X100V, there are only two settings relating to camera rotation that can be controlled:

  1. Display Rotation, which sets whether the viewfinder and LCD monitor indicators are allowed to rotate to match camera orientation; and
  2. Autorotate PB, which sets whether images are displayed in the "correct" orientation during playback.

The first setting is irrelevant to this discussion. The second setting only affects the second part of the image rotation problem (during viewing). I've looked carefully through the X100V menus and documentation and searched various forums, but cannot find any way to completely disable image rotation detection and the subsequent impact on the EXIF information.

Very much looking forward to hearing from anyone that's delved into this topic and has more familiarity with the X100V than I do!

 

 

 

 

 

Link to post
Share on other sites

Thanks, Greybeard. Your comment prompted me to delve deeper into what else is happening in the pipeline. Turns out that the RAF files have the correct image dimensions, although the orientation flag does change. We normally process through DXO Photolab and don't apply any changes to image rotation/orientation. However, it seems that Photolab swaps the width and height written in the EXIF information for any images that have a rotation flag that indicated portrait orientation! Naughty, naughty.

That means I can put in place a workaround where we search for any images with an orientation flag that's different from 'Horizontal (Normal)' and use exiftool to overwrite the flag to the desired value of '1'. It's a bit tedious, but can be done.

However, ideally I'd like to have the camera disable orientation detection and simply write all images as orientation '1'. Do you know if this is possible?

Thanks for your help.

Link to post
Share on other sites

5 hours ago, jerpol said:

Thanks, Greybeard. Your comment prompted me to delve deeper into what else is happening in the pipeline. Turns out that the RAF files have the correct image dimensions, although the orientation flag does change. We normally process through DXO Photolab and don't apply any changes to image rotation/orientation. However, it seems that Photolab swaps the width and height written in the EXIF information for any images that have a rotation flag that indicated portrait orientation! Naughty, naughty.

That means I can put in place a workaround where we search for any images with an orientation flag that's different from 'Horizontal (Normal)' and use exiftool to overwrite the flag to the desired value of '1'. It's a bit tedious, but can be done.

However, ideally I'd like to have the camera disable orientation detection and simply write all images as orientation '1'. Do you know if this is possible?

Thanks for your help.

I don't think its possible to disable the setting of the orientation flag (at least not on any X series camera I've used).

Your Exiftool solution seems reasonable - you could just apply the command to all images as part of the pipeline - you don't have to worry about what the current setting of the flag is - Exiftool can figure that out and only make the change if necessary.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Similar Content

  • Posts

    • A fungus in the forest.

      Welcome, dear visitor! As registered member you'd see an image here…

      Simply register for free here – We are always happy to welcome new members!

      (p.s. Open Topic.)  
    • The backslashes you are referring are just symbols denoting path.  Once you import into these LUTS into Davinci Resolve those backslashes are removed by default and you only see is the true file name which has no backslashes.  Convince yourself of this by opening the LUT folder from the Davinci Resolve Project Settings.  Do you see any backslashes in those LUT names? Of course not.  The only name you see is the one that has the underscores and the periods. These LUTS work as designed without having to change any path names.  However, they need to be set up properly through CSTs and by what is supported in Davinci Resolve.  Hence, the FLog2C film simulation LUTS cannot be used because Davinci Resolve does not support Fuji Gamut color space and the FLog2C gamut. Alternatively, Davinci Resolve does support Flog2 film simulation LUTS because the color space for FLog2 is Rec 2020 and there is an FLog2 gamut. If all you are doing is changing the path names then you are not getting the correct results.
    • I found the reddit topic i refere to :  https://www.reddit.com/r/davinciresolve/comments/1pc3f1e/cant_apply_new_fujifilm_gfx_55_lut/ "Update for y'all, It's just like what @ExpBalSat said, it's because of the backslashes in the names break them. I changed the file name and it works now. "   For me it was the solution. Realy annoying if it doesn’t work for you 😕  
    • Here is the solution to using the Eterna 55 file simulation LUTs in Davinci Resolve.   In general, do not use the FLog2C to film simulation LUTs as they are not supported by Davinci Resolve for two reasons: 1) Davinci Resolve does not support Fuji Gamut Color Space and 2) Davinci Resolve does not support FLog2C gamma.  Instead, use Flog2 which is supported by Davinci Resolve.  Here is an example.  Let's say that you want to use Classic Chrome simulation.  Do the following: Complete your color grade and use a CST to get to Rec 709. Add a node.  Use a CST to convert from Rec 709 to FLog2.  Output Color space is Rec 2020 and Outout Gamut is FLog2. Add a node.  Apply the FLog2 to Classic Chrome LUT Create a combination node from node in steps 2 and 3. Apply a Key to the combination node and adjust the Key Output Gain to get the amount of the combination node that you want applied. So that you do not have to do this over and over again, generate a LUT for the combination node.  Remember to turn off all other nodes before generating the LUT. Hope this helps others. Don  
    • Thanks for the insights. I think it's really hard to make a decision without having the two side by side! 
×
×
  • Create New...