Messages

Thank all the gods. May this abomination of a joke never rear its ugly head again.

I cannot help but wonder how changing the date was ever considered a sufficient workaround. Have none of you ever used sorting by date to split multiple days of a photo trip? Or, used time syncing to combine photos from several cams?

Okay, okay, it's dead, not beating it any more.

OK, here goes nothing. I committed a pull request trying to add an "--append-suffix" option to cr2hdr, making it write to "filename-DualISO.DNG", avoiding overwriting "filename.DNG". It's dry code, as I couldn't afford the time to set up a proper build env, so it may crash and burn... <_<

Right, I know how to fork and request pulls, but I was baffled by the apparent ability to edit and commit to the main repo, NOT my own fork.

Since I have zero experience with BitBucket specifically, I wonder why it lets me edit and "commit" the file..? I thought I'd have to fork the project and then submit a pull request, and yet there's the "Commit" button, beckoning... What's with that?

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 Expand

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

Code Select Expand

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?

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...

Oh my... Directly replacing the last 3 letters with "DNG" is probably one of the most horribly unsafe piece of code I've seen... O_O

Fsck it, I'm game. Where's the source code and how can I contribute?

@Walter Schulz: Huh, indeed I thought I mentioned this already, but wasn't sure if I did or only intended to. I need to replace some memory chips in my head, I guess.

I did a fresh installation of CR2HDR BETA 3 today, only to find it DELETES original DNG files after converting. What the hell!? Sure, it adds a -dualiso suffix, but only after overwriting the original file! And there's no option to disable that behaviour in the settings. Not to mention it also fails to copy the original's EXIF data to the dual-ISO file, so now I'm left with a bunch of nicely converted, but de-EXIF-ed files, thanks a lot. :/

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 :/

I'm using 3.0-BETA3 and I could swear it didn't do that before, but it's now DELETING the original DNG files, leaving only a -dualiso.DNG file present, much to the surprise of my Lightroom. I think it started happening when I set LR to convert files to DNG, whereas I had it set to import my CR2 files without converting. I'm not sure if it's cr2hdr or the plugin that's responsible; I'll make sure by running cr2hdr in command-line mode, if needed.

Also, it doesn't copy the original camera metadata into the dualiso file; rather, it sets my f-stop and exposure time both at 1, what's with that? It was just an annoyance before, as I could always look up these tidbits on the original files, but now that cr2hdr (or the plugin?) deletes my original files, I can't look at the exposure data anymore.

[@Licaon_Kter:]

@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.

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.

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.

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.

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.

9.54 fresh from the .lrplugin package.

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.

Hmm. I (mistakenly?) assumed a Dual ISO raw file would simply have 2 lines of brighter ISO and 2 lines of darker ISO. However, indeed taking bayer pattern interpolation into account, these might absolutely not amount to two lines of PIXELS being brighter and darker, since it's sensors playing hopscotch, not pixels in a resulting image.

Thanks for the explanation. The plugin indeed does seem to do the job of loading it, although I somehow expected it to split my image into two lower-resolution images for me to merge using Enfuse. Can this still be done, however?

@dmilligan: As mentioned, this is a screenshot from Lightroom, I'd assume it had already done all the interpolation a raw file needs...

@Walter Schulz: Raw Therapee is worse yet:


The raw file is here.

I'm getting odd "bleeding" from the bright stripes onto the dark stripes, as seen here:


Is this a problem only with older Canons like mine? And is there anything automated I can do about it? I mean, it's sure to wreak havoc on pictures after merging the exposures...

(This is an enlarged screenshot of a 100% zoom in Lightroom after converting the image from .CR2 to .DNG, if that matters.)