Dual iso missing Exif information

[chadat23]

I've been post processing dual iso pictures with BarracudaGUI, I have exiftool selected where it's looked for in the settings. It's in the same folder as cr2hdr.exe. However, after processing, when I look at the file properties all of the camera specific information is gone and only the basic file information remains. Any idea why this would happen or how to fix it? Thanks

Chad

[sinuspi]

Similar problem in LR here. Converted in command line, got EXIF data correct. Converted using LR plugin, got no EXIF.

EDIT: Issue later proven to be local to a specific file, not to command line working and plugin failing.

[Walter Schulz]

Exiftool version in <plug-in directory>\bin?

[sinuspi]

9.54 fresh from the .lrplugin package.

[sinuspi]

Huh, now I tried on another image and the EXIFs were preserved correctly. Checking what could be different here...

Edit: I may be digging myself into a rabbit hole here, but... The base file is IMG_8063.dng. A manually converted file, IMG_8063-manual.dng, as well as another file I converted with the plugin just now, IMG_8072-dualiso.dng, have original EXIF data preserved. However, IMG_8072-dualiso.dng (exported using the plugin) has not only missing EXIF data, but a "Canikon" model of Canon as the camera used, and a 1.0sec @ f/1.0 exposure.

[Walter Schulz]

Do you have two different cams?

[sinuspi]

Nope. I wish I had.   Both are Canon 550D. I can upload the CR2s and LR-made DNGs somewhere if that helps someone analyze what happened here.

EXIFs are:

Original image that converts badly:


Converted in plugin:


Converted by command line STRAIGHT FROM CR2:



EDIT: Well, great. I noticed that the good conversion came straight from a CR2 file, so I went and converted the DNG using command line... and the tool overwrote my DNG. Now I'll have to import it again if I'm to analyze it further. But, the good news is, the resulting converted DNG has proper EXIF data, consistent with the command-line tool working properly.

EDIT 2: Correction, the resulting DNG also had wiped EXIFs.

[Walter Schulz]

Case closed?

[sinuspi]

Not necessarily. If anyone can shed light on the circumstances in which the plugin's actions would result in a "Canikon" camera entry being put into the EXIFs, it could help analyze this, perhaps.

[dmilligan]

Plugin calls cr2hdr to convert the image. cr2hdr creates the converted DNG with mostly empty metadata (including the Canikon thing), then cr2hdr calls exiftool to copy metadata from the original cr2 or dng to the newly created one. If exiftool is missing or fails, the metadata in the converted file will be mostly blank (like the way you saw).

[sinuspi]

Well now I've conducted a full experiment:

1. IMG_8063_weird.CR2 is our main protagonist.
2. Commandlined: IMG_8063_weird.CR2 to IMG_8063_weird-cmdlinedualiso.DNG -- has EXIFs correct.
3. Imported to LR 5.5, without DNG conversion.
4. Plugined: IMG_8063_weird.CR2 to IMG_8063_weird-dualiso.DNG -- has EXIFs correct.
5. Converted to DNG inside LR, fiddled to name it IMG_8063_weird-lrdng.DNG.
6. Plugined: IMG_8063_weird-lrdng.DNG to IMG_8063_weird-lrdng-dualiso.DNG  -- has EXIFs MISSING.
7. Commandlined: IMG_8063_weird-lrdng.DNG to IMG_8063_weird-lrdng-cmdlinedualiso.DNG  -- has EXIFs MISSING.
8. Verified that both sets of outputs are byte-identical, so using the plugin or command line doesn't matter.

Seems like the tool can't handle this file after LR manhandles it.

EDIT: If someone wants to look at it, here it is in all its 17 MB glory.

[Licaon_Kter]

What if you put exiftool.exe in c:\Windows ?

[sinuspi]

@Licaon_Kter: Won't matter; I'm running it from the very folder it's in.

C:\FOTO\cr2hdr.lrplugin\bin> cr2hdr c:\foto\2016-01-20\IMG_8063_weird-lrdng.dng

It doesn't get any more direct than this.

[sinuspi]

A year later, this is again a problem. Especially nasty now that cr2hdr BETA 3 replaces the original DNG files. So now it replaced a bunch of raw dual-iso DNG files with proper EXIF data with HDR images missing EXIFs entirely :/

[Walter Schulz]

Make sure to use latest binaries and plug-in. The one linked in first post is *not*. See https://bitbucket.org/kichetof/lr_cr2hdr/downloads/

Do you import data into LR as DNG? Use CR2 instead and you will have no troubles with outdated tools overwriting existing files.

[sinuspi]

I guess it makes sense that if it replaced the original DNGs, it had no file to copy EXIF data from anymore. Luckily, I was able to rename all of the IMG_1234-dualiso.DNG files back to IMG_1234.DNG that were still in Lightroom's library and have it write metadata back into the files, so nothing was lost.

Ah, I was sure the sticky post had the newest version. OK, I'm now on BETA3.3 and it doesn't overwrite IMG_1234.DNG anymore (though it says in the .txt logs that it copies EXIF metadata from "IMG_1234-dualiso.dn6", which is the suffixed name with a number six replacing the last character, for some reason). And, EXIFs are present, correctly.

EDIT: Oh. This newest version converts everything even if no striping is detected, creating -dualiso suffixed exact copies of source files. How do I get it to ignore non-dual source files..? I used to be able to just select a whole folder of photos and let the plugin do the work, converting only striped images...

[a1ex]

If you are using the command-line version for troubleshooting, pasting the conversion log should help us figuring out what happens. Otherwise, it's impossible to guess.

[sinuspi]

It's a separate issue now, I guess. I made sure that the command-line version doesn't copy the source file if there's nothing to do - so it must be the LR plugin that's not recognizing a "Doesn't look like interlaced ISO" response.

(Digging.)

Indeed. The LR plugin first copies the source file to a safe new name (with a suffix):

Code: [Select]

LrFileUtils.copy(originalFilePath, newOriginalFilePath), then has cr2hdr convert that, and afterwards it checks for the presence of the suffixed file:

Code: [Select]

LrFileUtils.exists(finalPathDNG) ~= false. So, as long as DNG files are in use, it'll never skip importing or delete the copy it made. I'll see if I can rig the plugin to actually detect what cr2hdr wrote into its .txt log...

(EDIT)
OK, I made a few changes to the LR plugin's MLProcess.lua file, making it remember its act of copying the source to a new file, and recognize when cr2hdr did nothing to the copy - thus inferring when the "output" file can safely be deleted, and properly chalked up as "Not Dual ISO".

Who should I run these changes by?

[nikfreak]

Kichetof's LR Plugin got last update over a year ago. You could try to create a PR for him or fork his repo or just make your changed files public elsewhere...