Image rotated after batch processing

[Aubrey]

After I perform an action in the image batch processor my vertical (portrait) images are rotated to landscape. I thought that the processor would see the EXIF orientation and keep this.
It's not a big issue as then I select rotated images and apply: Rotate and Transform | Lossless rotate for jpg files

However perhaps I'm missing something in my workflow that will automatically allow correct orientation....

Thanks,
Aubrey.

[Mario]

Usually this just works...

We would need a bit more info to work with, e.g.
Which file format do you use?
Do you have virtual transformations for the file?
Is the EXIF orientation record int he file valid?
Which operations do you perform in your batch processor preset.
...

[Aubrey]

More information...
Workflow NEF imported into Lightroom 6.1.1 using the IMatch , export function (dropping the image onto Favorites/Applications)

Then the image is exported from Lightroom and read back into IMatch as DNG file after processing.

I then prepared a JPG from the DNG using the IMatch default values in "For Web (800 x 600 JPEG)" batch processing.

This jpg, generated from the DNG, is rotated

I checked the NEF file and a jpg generated from the NEF file is OK, i.e., not rotated.


It looks like the issue is coming from the Lightroom export.

No virtual transformations have been applied.

I am using external GUI viewer for EXIF data. What parameter should I look for to find the rotation information. I ahve looked thorugh the (long) list of parameters in both the NEF and the DNG, but I have not found the orientation reference... what words should I look for?

This is not urgent but I would like to get to the bottom of it if possible, for the few images I convert I can do a lossless rotate.

Thanks,
Aubrey.

[Mario]

Does the file exported by LR contain a crop record in the XMP?
It would help if you can provide a sample NEF and your Batch Processor preset settings so I can see the file you work with.
Also check in IMatch (Edit > Preferences > Metadata > File Formats.. for NEF DNG JPG if you have support for XMP crop enabled.
Do you copy metadata into your output file in the Batch Processor? If so, which metadata.
Tons of metadata are swapped around by LR when it produces DNG from NEF files, so much can cause troubles...

[Aubrey]

Mario,
I need to put this on hold as I will be traveling over the next 10 days.
Aubrey

[Hordor]

Mario,

I had a similar problem using the batch processor. My workflow is:

1. Copying pictures from Canon or Olympus Raw on Harddisk in my IMATCH-Import directory.
2. After setting keywords and rating rename and copy via batch-copy to RAW-Master directory (sorted by Year and month).
3. Pictures with stars will then be send to DXO via Favorites.
4. Processing RAW File with DXO generating a TIF-File with 16bit, ProPhotoRGB. Saving in my Master-TIF directory.
5. Starting Versioning (by Filename/Extension). Copy Data from RAW to TIF - including orientation (This caused the problem).
6. Batch processing TIF to JPG (8bit, sRGB) without resizing. Saving in sRGB-Directory.

Pictures with Portrait-Orientation are displayed correct in IMATCH before batch-processing. When opening in Photoshop they were displayed rotated by 270°. Depending on metadata-setting in batch-processor the processed jpg had two (wrong) orientations:
1. Copying only ITPC/Keywords or no metadata the picture will be turned 270°.
2. Copying all Metadata or only EXIF-Metadata (with or without Maker-Notes) the picture will be turned by 180°

The fault was not in the batch-converter but in copying orientation data from RAW to TIF. The solution was to correct versioning so that orientation is not copyied. In my case I had to remove orientation data from the EXIF of my already processed TIFs. As Metadata is transferred automatically via Versioning betwenn TIFF and jpeg I do not transfer any Metadata during batch-processing.

Hope that helps.

Uwe

[Aubrey]

Mario,
I have a DNG portrait file came from a CR2 file after processing in LR6. (I attach the metadata extracted using exif. The file is too big to send).

I then ran the file through the batch processor (batch processor file attached). The jpg file is rotated (attached)

It does not make sense that the file gets rotated after running through batch process, suggestions?

Thanks,
Aubrey.

[Mario]

Do you copy metadata to the output file?
Is the original file rotated via the EXIF orientation tag?
Do you use the original file in the Batch Processor or the cache file?

Usually a wrong orientation is caused by copying EXIF metadata, including the EXIF orientation tag.

[Aubrey]

There has been no rotation of the original file. Image was taken with camera vertical to get portrait as opposed to landscape.

I don't know what is meant by file being rotated by EXIF orientation tag (how can I check), As I said camera was in portrait as opposed to landscape position. As camera has horizon level check, I expect it knows the orientation of camera when shot is taken. (Canon G16)
The metadata selection in the Image processor is set as follows:
XMP:Description ticked
XMP: All Data ticked

Always write metadata into output file ticked.
I have used both original and cached version with similar results.

Which exif parameter defines the image orientation?
Is it {File.MD.XMP::tiff\Orientation\Orientation\0}

What I don't understand is that a portrait DNG image with all metadata written, which appears ok in viewer becomes rotated when I create a jpg using Image Batch Processor.

I can send you the DNG file if it helps...

Thanks,
Aubrey.

[Mario]

Does the output file have EXIF data?
Add it to IMatch and check if the orientation flat is 0 (Neutral/Default).

[Aubrey]

The process I was following :
Created jpg and loading into folder {p0}/hash This was then automatically found by IMatch. The file was presented in landscape format.

Following your question, I used the following workflow:
Configured batch processor to send  jpg to d:\
Dragged and dropped resulting jpg into a new folder (hash1) of IMatch
File is correctly presented in portrait format
parameter: {File.MD.XMP::tiff\Orientation\Orientation\0}
Orientation   Rotate 90 CW

Then tried first method again into this (hash1)folder the file created is landscape format.
parameter: {File.MD.XMP::tiff\Orientation\Orientation\0}
Orientation   Rotate 90 CW

There appears to be an issue when file is immediately loaded into IMatch

Observation:
When the files are viewed in windows explorer (large icons selection) the files from both methods appear as landscape.

[Mario]

IMatch respects the EXIF orientation (not the one in XMP).
If the original image has to be displayed rotated by 90° to the left, IMatch will do this.
If you convert the image in the Batch Processor, it will process the already correctly oriented image.

Copying EXIF data from the original image will copy the wrong EXIF orientation and the output image will appear in the wrong orientation.
Copying all XMP data will do the same, because on write-back, the XMP orientation copied from the original file will be mapped back to EXIF.

First step: Don't copy any metadata into your output file. Does this solve the problem?

[Aubrey]

I have tried to batch process file without creating any metadata, however, metadata is still being written, this has me very puzzled.

I attach a jpg, to show the
(see dump of the metadata section before batch processing)
I also attach a debug log file.
This file is relatively short.
Opened IMatch
Performed batch processing
Looked at the result
Exported log file.

Aubrey.


[attachment deleted by admin]

[Mario]

Some Metadata is always written for JPEG files, e.g. a minimum of EXIF data.
It would have helped if you had attached the resulting file. So far I have neither seed the data for your original file, and neither the output file.
I made a test and when batch processing a JPEG file with non-default orientation (e.g., 90°) it ends up correctly orientated in the Batch Processor result. I've also tried a NEF and a DNG file.
I don't think you answered that yet: Do you use the original image for batch processing or the cache file (default)?


Best to send me your Batch Procesor Preset settings and your DNG file. Else we waste our time poking here and there...

[Aubrey]

Best to send me your Batch Procesor Preset settings and your DNG file. Else we waste our time poking here and there...

I agree!

I thought I had sent you the batch processor file, but on checking back I find that I did not attach it. It's attached here.

I  also attach the jpg result, but I cannot attach the DNG file as it is too big.

I have tried to log into the ftp server. but the password has changed. Last log in was October 2014.
Aubrey.

[attachment deleted by admin]

[Mario]

Send me the file via email (see the link below in my signature).
I change the FTP password all the time, because my FTP was hacked last year because the password was stolen from an IMatch user.

The JPEG looks OK? It contains no EXIF orientation record.
Can you attach it again, zipped? This prevents the community software from changing the metadata,

[Aubrey]

Find attached the jpg, zipped.
This was generated from DNG file: AOC_G16_160126_1217.dng which I will send by email referencing topic 4845.

You are correct in noting that the community software was stripping metadata. It is certainly present when I view the jpg in IMatch; this is despite me setting up no metadata in batch processing as shown in IMBPP file you already have from previous thread on this topic.

Aubrey.

[attachment deleted by admin]

[Mario]

You are correct in noting that the community software was stripping metadata. It is certainly present when I view the jpg in IMatch; this is despite me setting up no metadata in batch processing as shown in IMBPP file you already have from previous thread on this topic.
Aubrey.

Maybe you have a XMP file for the JPEG? If an XMP file wit the same name as the JPEG file exists in the same folder, it will be imported. By definition, an XMP file belongs to all images with the same name in the same folder.

[Aubrey]

Maybe you have a XMP file for the JPEG? If an XMP file wit the same name as the JPEG file exists in the same folder, it will be imported. By definition, an XMP file belongs to all images with the same name in the same folder.

Mario,
This was useful information, and it has enabled me to progress further with the troubleshooting.
I have always been exporting to a separate folder. today to {p0}/test.
I do not automatically import into IMatch.

Test 1:
After export checked file using exifGUI, no exif data.
Then do
Rescan Now with IMatch (did NOT use CRTL SHIFT), the folder test is found and the file imported. Now the contains EXIF data and file rotated incorrectly

Test 2:
After export checked file using exifGUI, no exif data.
Then do:
Commands |Add or Update folders navigate to folder test and load. No EXIF data is loaded. Yipee!!
Then performed F5 CRTL SHIFT on the file, and still no exif data loaded.

Test 3:
After export checked file using exifGUI, no exif data.
Then do:
Commands |Add or Update folders navigate to folder test and load. No EXIF data is loaded.
performed F5 CRTL SHIFT on the parent folder. now EXIF data loaded and file rotated incorrectly.

So having narrowed down the issue to using "Rescan now", the question is why is EXIF loaded when I perform a "rescan now" in order to bring the folder into the database? Also from where is the EXIF information coming?

I made a further test renamed the file to something that has not been used and therefore database will have no knowledge of it, during batch processing. When file is exported there is no exif data (using exifGUI). Therefore from where does IMatch find the exif data of this file when "Rescan now" is applied?

The puzzle is getting smaller

Thanks,
Aubrey.

[Mario]

So having narrowed down the issue to using "Rescan now", the question is why is EXIF loaded when I perform a "rescan now" in order to bring the folder into the database? Also from where is the EXIF information coming?

IMatch produces an XMP record on import for each file. If the file has no EXIF data, the corresponding tags in the XMP record will be empty. Except some EXIF tags filled in by ExifTool for some formats, e.g JPEG files. This new XMP record is usually marked as 'pending write-back' because unless the data was written once by IMatch, new data is usually created during import.

If you have configured IMatch to automatically write back metadata, and the output format supports EXIF data (JPEG does), ExifTool will map from XMP to EXIF and produce an XMP record. This is required. But ExifTool does not create a orientation record out of thin air to my knowledge. What orientation is written to the file? You can see it in the Metadata Panel in the Browser mode.

[Aubrey]

What orientation is written to the file?

From Metadata Panel Browser mode:
{File.MD.Exif::Main\274\Orientation\0}

The orientation is: Rotate 90CW

See also attached screen dump

Is it possible that the issue could arise from the versioning parameter setup?

Some further information:
I tested an image using D300 NEF. Everything works fine. When I perform resscan, folder appears with the image, furthermore no EXIF data is loaded which is correct.

So the problem is camera related only found with my Canon G16  images.

Aubrey

[attachment deleted by admin]

[sinus]

Hi
I hope not to hijack this thread.

I can take what images I want (nefs from different cameras, jpgs), to change the rotation I can simply change the Rotation in this tag:
{File.MD.XMP::tiff\Orientation\Orientation\0}

This is a bit curious. Because the other orientation tag
{File.MD.Exif::Main\274\Orientation\0}

has a drop down with values like
Horizontal (normal)
Rotate 180
Rotate 90 CW
...

If I change this tag with help of the dropdown, nothing happens, after a write-back (in case of the nef to a xmp, the jpg to the jpg itself), the previous value is again here.
So the thumb does not rotate.

But if I do this in the xmp-tag (above), if I write exactly the same value, like Rotate 180, then after a writeback the image in the Quick View is turned and after a "Force refresh" also the thumb is turned.
So for me this xmp-tag works perfectly, the only issue is, that I have to write the values correct, because there is not a dropdown.

So this is why I ask here only, Mario, is this by behaviour? If the rotation would happen, if I would use the exif-tag with its dropdown, I would think, this is correct.
But in this case I must use the xmp-orienation tag (without the helpful dropdown).

This is not a problem for me, wanted only to remark this, just in case.
(I wonder, how many lines of code IMatch has, it must be soooo easy to change one line and we (and Mario  ) has big problems.)

BTW: all my new files works native perfect, orientation is correct, I refer above to old images, hence I have actually not this problem.

[Mario]

1. If ExifTool supplies a "list of values" for a tag (like EXIF orientation), IMatch displays it.
2. EXIF\Main\bla and Tiff\Orientation are synchronized by MWG rules during write-back. if you change only one, and the other tag is written later or considered more important, it will win. This is why your changes work when you change tag a, but not when you change tag b. These tags are not meant to be modified by users. You camera / RAW processor / image editor sets them and they should stay that way. Unless you have very good reasons to change them, and then you now know which tag to change so that the write-back also updates the other EXIF tag, and more important, also the real orientation tag in the real EXIF record.

[Mario]

So the problem is camera related only found with my Canon G16  images.

OK. Only when you process G16 RAW files via the batch processor into JPEG files the problem happens.

You are working with RAW files?
I assume you are using cache files for the Batch Processor?
This means that the Batch Processor uses an image file produced by the RAW codec installed on your system, which uses either the embedded preview (if available and large enough) or the full RAW image.
The result of this is then batch processed into a new JPEG file.

There are multiple potential EXIF orientation records at play here.
Please send me one of your image files which produces this effect. Maybe the orientation record does not match the RAW/preview data or something. Experience tells me that issues which only show up with images from a certain camera model / software, are usually caused by some problem with that camera / software, not IMatch.

[Aubrey]

I assume you are using cache files for the Batch Processor?

I am not using the cached image for the batch processing, there is no tick in that box.

I've checked both with and without tick and the result are the same; rotated image.

Remember that the issue of rotation occurs when I go to a higher level folder and right click and select rescan now.
If I load the newly created folder  after batch processing using Command | Add or update folders, and then navigate to new floder then the image is correctly orientated.

I will send an example DNG file by email, quoting the topic 4845

Aubrey.

[Viscus]

I have the same problem with RAW (.CR2) Files processed by Lightroom and afterwards imported in a subdirectory in imatch. It's only with pictures in portrait orientation.
After import i can see a little bit more information in different fields. In the windows view is the picture already rotated to landscape. But in IrvanView i can see it in the portrait orientation. After write down from imatch the picture rests in landscape orientation in windows and also in Irvan View.
I can test it also in DXO. I i remember right i didn't had this problem. The Checkbox to remove Orientation Information in Lightroom is unchecked.

If you want i can send you a picture with every step and also an export from DXO.

In the versioning i have already changed from XMP, every data to XMP without LR/Camera Data.

I didn't found a solution to export with Lightroom the right orientation flag for the pictures. And with google i didn't found a solution :-(

[Mario]

@Aubrey: I have not received your sample file yet.

@Viscus: I'm not sure that I can follow. Where do you see the image with the wrong orientation? in IMatch? In Explorer?
IMatch imports RAW files via Windows WIC codecs. It checks the EXIF orientation tag and applies the orientation reported there. If the EXIF orientation tag is not correct, the image will show wrong.

[Viscus]

@Mario: In Windows Explorer. In imatch the picture is always visible in correct aspect. But in Windows the picture change the view from portrait to landscape after import. But only for the picture which has no orientation information in it. I don't know why Lightroom isn't exporting the information. I took the same picture from lightroom made the rotation in Windows and afterwards nothing was changed in the import in iMatch.

I will send you the download link to the Files. I made after exporting from lightroom and dxo and from the rotated image also an Exif Export.

[attachment deleted by admin]

[Mario]

@Mario: In Windows Explorer. In imatch the picture is always visible in correct aspect. But in Windows the picture change the view from portrait to landscape after import. But only for the picture which has no orientation information in it. I don't know why Lightroom isn't exporting the information. I took the same picture from lightroom made the rotation in Windows and afterwards nothing was changed in the import in iMatch.

I will send you the download link to the Files. I made after exporting from lightroom and dxo and from the rotated image also an Exif Export.

The "LR" file you have sent to me contains:

1. No orientation information in the EXIF record
2. A Rotate 90° right orientation info in the XMP-tiff:Orientation record

And this is the problem. The orientation info in the EXIF record is missing (which means 'no rotation') but the XMP orientation data specifies a rotation. These two fields must be synchronized.

When IMatch loads a file into the Viewer or the QuickView Panel, it asks WIC for the orientation information.
For this purpose, it reads a so-called metadata policy with the name System.Photo.Orientation. According to the WIC documentation, WIC fills this data by first looking at the standard EXIF orientation tag and if this is not found, it looks at the orientation tag in XMP. If data is found it is returned as the orientation of the image, else an error is returned.

In case of the file you have classified as "LR", the file contains an EXIF record with no orientation info. The XMP record contains 90° right orientation info. Windows WIC hence returns to IMatch that the image has to be displayed right by 90°. And IMatch does that, which is correct.

When you write-back the file, IMatch synchronizes XMP data back into EXIF (and IPTC, GPS) according to the Metadata Working Group rules. This means that the orientation in XMP (imported from the LR XMP data) is written back into EXIF, in order to keep both metadata in synch. Afterwards both EXIF and XMP orientation data is synchronized, but wrong.

When you now change the XMP orientation in IMatch again (Metadata Panel) and set it to the value Normal and write back again, both EXIF and XMP orientations are set to normal and the file shows up correctly.

You can fix these files in the ExifTool Command Processor in IMatch by running this command:

-overwrite_original
-xmp:orientation=
{Files}


I think this is a bug in the metadata produced by LR. They should either write the same value for both EXIF and XMP orientation, or leave both empty.

[Aubrey]

@Aubrey: I have not received your sample file yet.

I wondered why you had not replied... following your message, I have checked and found the email in my draft folder and have now sent it.

If you have NOT got it next time you check please let me know.

apologies,
Aubrey.

[Viscus]

Thanks Mario

My solution is to change the Orientation by hand over the Menu Rotate and Transform -> Orientation (Exif) and set to Normal.
It is a mess why LR isn't writing the correct information. And for the other side the RAW has another Orientation Information than the JPG.

I'm only wondering why this problem wasn't discussed before.

[Mario]

I'm only wondering why this problem wasn't discussed before.

The image library IMatch uses for creating the thumbnails only understands EXIF and hence the thumbnails are not rotated (and correct in your case). But the switch to using WIC and DirectX rendering last year (5.5+) also caused a change in orientation handling in IMatch. WIC always looks at EXIF first, then falls back to looking at the TIFF XMP orientation. I assume that there are good reasons for this and I don't want to change this.

So far it seems that only you had the problem with different EXIF and XMP-TIFF orientation values in files - at least I don't remember similar reports via email or here in the community. Maybe it's the specific LR version you are using, or the specific way you use it, the way your camera writes the original EXIF data etc. ...

[Viscus]

I used a long time DXO as RAW Converter. Since spring i tried to use LR and i had the problem since then. I use Lightroom CC. But i was a little bit slow with converting pictures from lightroom and the problem was now more urgent for me. And my research found this thread also.

Hope Adobe will change the behavior but we don't know when. If someone is reading here in the community about the same problem it would be very helpful.