Nikon Vertical Images

[Mike Buckley]

(There are several ways to correct this 'per photo' the easiest one being rotating them in the full screen mode, using the right tab of the mouse)

I assume doing that produces the same results as rotating when viewing the thumbnail image. If so, when using Supreme's Batch panel to then create a JPEG from the rotated NEF, I haven't found a way using Supreme to generate an image that displays the orientation properly in both Supreme and Windows.

Later today I plan to provide a NEF, its XMP file, a JPEG produced as described above, and the Batch file used to produce it.

[peter wijn]

ah, yes, didn't that one yet, you wrote about it above I realize now, thanks Mike

[Mike Buckley]

I'm finally back to working on this issue. Sorry for the delay.

Please use the link shown below to download my NEF, its XMP file and the batch file that I use to create JPGs from my NEFs (Nikon's RAW file format). You probably know to place the batch file in your %localappdata% IDimagerSystemsInc/Batches folder. The NEF is oriented vertically. However, once I use Supreme's batch file to create the JPEG, when Supreme displays it correctly Windows displays it incorrectly and vice versa.

I realize that I might be able to solve the problem by using Capture NX2 to batch create the JPGs. Alternatively, opening the JPEGs or the NEFs in Capture NX-D and batch changing the orientation might also solve the problem. I think it was Lippe who also suggested using external software to attend to the orientation metadata. I'd rather not have to do any of that because my ideal workflow would involve using only Supreme as I always did when using IDimager. Regardless, thanks to anyone interested in using my files to take a look at the issue.

https://www.dropbox.com/sh/7f5hxwsb6q8p ... gTO4a?dl=0

NOTE: When you run the batch, configure the newly created image to be stored in a folder that is different from the folder the original is stored in. Otherwise, a bug prevents the newly created file from being versioned.

[lippe]

Mike,

Some things i observed:
I don't have a folder C:\users\Mike Buckley\... so i changed the folder to safe to the same folder.
When running your batch on the example nef, it turned the nef thumb! While rebuilding the thumb will display it again correctly. there is something not right.
The images are not versionized. To get the orientation of the jpg corrected, i have to turn in 180 degrees. (=Counter clockwise 90°)

I run the batch a second time on a new copy, but now saving it to a other folder and also disabled the 'Write metadata; if available" in the file format conversion, the batch behaves normally: Both nef and jpg are now versionized. Both nef and jpg are correctly orientated. Also Windows explorer and FPV displaying both correctly orientated.
Of course the meta information is now missing. I used the cascade in the version menu and selected all options (including xmp) because i can't find the operation in the batcher.

I remembered now why i did not used versions. There are some odd things when changing orientation of versioned images.

Lippe,

[Mike Buckley]

Sorry, Lippe. I forgot to remind everyone to save the versioned image to a different folder. I'll change my earlier post. A bug requires saving it to a different folder in order to allow the newly created image to be versioned.

[Mike Buckley]

disabled the 'Write metadata; if available" in the file format conversion... Both nef and jpg are correctly orientated. Also Windows explorer and FPV displaying both correctly orientated.

Very, very promising! I have to run out the door, return quickly, and fix the evening dinner. I'll check this out on my system later tonight and get back to you. Thank you!

[Mike Buckley]

A huge thank you to Lippe! I just now applied the batch file with its new configuration according to his instructions to 74 vertically oriented images and all of the newly created images display properly in both Photo Supreme and Windows. This seems to have solved my problem. The very slight change to my workflow that will be required is not an issue for me.

[lippe]

(my apologies to the non techies, just skip this annoying post)

Hi Mike,

Even you marked the topic as SOLVED (and a moderator could close it), i tried to understand what is happing in you workflow to find out if there is a bug with general raw/or just with Nef.

Breaking up you Batch; the first two steps are difficult to examine as no output is possible. I assuming Photo Supreme load the nef (libdcraw) in memory resizes and sharpen.
The third step is the first producing an jpg output file. In your original batch with 'Write metadata; if available" enabled, it is going wrong: The beautiful lady on the jpg thumb is rotated wrong by adding a 90°to the already 90° turn of the original, resulting in a horizontal position (180° turned compared to the original). The nef is still alright.
In windows and FPV both files are correctly rotated! The jpg orientation i set to 'Normal' even the image is rotated correctly.
It is getting more weird when i open the jpg in PSe. In the PSe properties of the file, i find:

Code: Select all

<tiff:Orientation>1</tiff:Orientation>
...
<rdf:Description rdf:about=""
            xmlns:iles="http://ns.idimager.com/iles/1.0/">
         <iles:IsEnabled>1</iles:IsEnabled>
         <iles:RecipeName>Recipe</iles:RecipeName>
         <iles:Rotate rdf:parseType="Resource">
            <iles:RecipeEnabled>1</iles:RecipeEnabled>
            <iles:FriendlyName>ROTATE</iles:FriendlyName>
            <iles:Opacity>255</iles:Opacity>
            <iles:BlendMode>1</iles:BlendMode>
            <iles:Angle>+90</iles:Angle>
            <iles:Crop>0</iles:Crop>
            <iles:BackgroundColor>0</iles:BackgroundColor>
         </iles:Rotate>
      </rdf:Description>

While the idimager section looks like a recipe and i doubt PSe will apply this recipe to the image, the first part is indicating the tiff orientation to 1, and this is not 'normal'. However the image is 180° turned compared to the thumb.

I retried the third step but now with the "Store created file as new version" disabled. This is resulting in the same wrong jpg. However, also the nef is turned 180° IN the other direction;

I'm starting to loose any confidence to solve the problem and are in urgent need of a cup coffee, but not before i fired exiftool(GUI) to get at least my orientation back:
Exiftool indicate :
Exif (IFD0) - Orientation : Horizontal (normal)
XMP (XMP-tiff) -Orientation :Rotate 270 CW

[Mike Buckley]

I hope your cup of coffee was satisfying, Lippe. To further complicate things:

When I import NEFs from my wife's D5100 as they are being downloaded from the memory card, all of the vertical images are displayed horizontally in Photo Supreme. They have to be corrected by rotating them 90 degrees clockwise. (I don't know how they are displayed in Windows because I never review the image content of RAW thumbnails. In fact, I have intentionally not installed the Nikon Codec.) NEFs captured with my D7000, which is one generation earlier than my wife's D5100, don't have this issue.

[lippe]

Mike, thanks. I enjoyed my espresso together with some Belgian cookies! Now I'm armed to get further digging in the Photo Supreme rotation.

For testing purpose; i have copied the same beautiful-lady-nef and xmp-sidecar in to several subfolders and imported them in my catalog. Without even running the batch, there was one folder where the thumb orientation in Photo Supreme was not correctly. I had to rebuild the thumb.
Occasionally, also thumbs created from my cr2 raw files have the wrong orientation. If i verify the file, i cannot find something wrong. If i rebuild the thumb, it is correctly rebuild.

I noticed the software tag in exif has the string 'Capture NX 2.4.7 W'.
To try with fresh images, i downloaded some nef sample images from a Nikon D7000 like yours, and some like your wife's camera, the nikon D5100 for testing.
While my test cannot represent the experience you have with nef images, all thumbs of 'vertical' nef images are during import correctly displayed for both camera's.
The 'Vertical' test images are all rotated 270 clock Wise. The one you provided is Exif (IFD0) - Orientation : Normal.
I don't have Capture NX for testing but is it possible it changes the nef?

[Mike Buckley]

Nikon D7000...nikon D5100 ...all thumbs of 'vertical' nef images are during import correctly displayed for both camera's.

I wonder if there is a camera setting of the D5100 that affects this. I'll look into that. I have had the same issue every time I download D5100 files whether using IDimager V5, Supreme V2 or Supreme V3.

I don't have Capture NX[2] for testing but is it possible it changes the nef?

Anything is possible with Capture NX2 including that it is doing something on my system that it doesn't do on other systems. The software has always been noted for its quirkiness in that regard. I'm not concerned about this particular issue because it consistently behaves (or misbehaves) this way on my system and it is easy to change the orientation.

Thanks for continuing to look into this stuff. I hope you enjoy doing it because I sure don't.

[Mike Buckley]

Very interesting! The only way I can get the D5100 files to display vertically upon download is to set "Auto Image Rotation" in the Setup menu to "OFF." However, doing so displays the image in the camera's LCD in the "short" version that doesn't fill up the entire LCD. When configuring the same setting on the D7000 to "ON," the downloaded images are displayed correctly and the image is displayed in the camera's LCD in the "long" version that fills up the entire LCD. So, apparently I can get the best of both worlds only when using the D7000, not the D5100.

By the way, it's very convenient that you have the same camera models that I have.

[Mike Buckley]

I just now discovered a new problem related to the fix that Lippe came up with. When using the Batch file to create a versioned JPEG from the RAW file and when writing metadata to the newly versioned JPEG is disabled, the Date Time Original becomes the date the version is created, not the date the RAW file was captured. Worse yet, the Catalog Explorer's "By Date" displays the versioned file as of the date it was created, not the date the image was captured.

So, I have to ask: Is the requirement to disable writing the metadata to the newly created JPEG a Photo Supreme bug or something more likely having to do with Nikon Capture NX2 messing up the RAW file? EDIT: As a later post indicates, that setting can be enabled if the command, "Convert Metadata to XMP," is first applied to the NEFs.

[lippe]

Mike, i don't know for Nikon camera's, but on older Canon, disabling the auto rotation, will result in also not writing the orientation in the exif. Newer Canon models have 3 options for auto rotate OFF/Computer only/Camera + Computer. Immediately after shooting, the image is always displayed in 'normal' on the back LCD. When reviewing the images on the camera, it displayed like the rotate setting is set. There is an option to rotate an image on the camera. When pointing upwards or downward and you do not like the rotation.

I checked the disabled 'writing the metadata' EXIF in the test file. There is no EXIF thus no photo date. Photo Supreme will use file date, the date Photo Supreme created the jpg. it seems my solution is also unacceptable.

I tried the first 3 steps of your batch on the fresh test images: i import them in Photo Supreme using the Verify folder methode, sync the imported files. run your batch with only the resize + sharpen + convert to jpg with meta en turn of the versioning. The by Photo Supreme created jpg is displayed with the wrong orientation in the collection viewer, also in windows and FPV.
I think this is a bug in Photo Supreme build 2055. I will redo the test on a cr2 file and is the result is the same, report this in mantis.

Currently, you cannot use Photo Supreme to create jpg files from nef raw files. Also I would not recommend to use the recipe based rotation on raw files.
I tested in Lightroom, all images are rotate correctly. Verified in exiftool: all exif/xmp is present, the orientation is stripped because the image data is rotated and therefore not needed. (Is this the bug in Photo Supreme?)
Mike, you can verify in Nikon Capture NX2 how the jpg is exported. I will taste my Kasteelbier now

[Mike Buckley]

Lippe,

I think I beat you to your Kasteelbier with a glass of Pinot Noir.

Considering that you apparently regularly report stuff in Mantis, you might want to determine if the following has been reported there: using the Batch panel to create the versioned file requires saving the newly created file to a different folder. I discovered that when I began using V2 a month or so before V3 was released and Hert reproduced it. I didn't add it to Mantis and I don't know if anyone did. (I don't like using Mantis.)

Using Capture NX2 to create the JPEG from the NEF does not place data in the Date Time Original field, so that's not a solution either.

I currently seem to be caught between two choices, neither of which are ideal. I can use the Batch panel to create the JPEG, write the metadata to the newly created file and the Date Time Original will be correct but I won't be able to display the vertically oriented photo correctly in both Supreme and Windows. Alternatively, I can use the Batch panel to create the JPEG, not write the metadata to the newly created file, and the Date Time Original will be incorrect but the I'll be able to display the vertically oriented photo correctly in both Supreme and Windows.

If I choose the second method, I can easily correct the date of the Date Time Original field but I could never justify making the effort to look up the time and then add it to that field. At this point in time and until the bug is fixed, I'm strongly leaning toward the second method, changing the date of the Date Time Original and leaving the time at 00:00:00.