Lightroom plugin cr2hdr v3.0 DEV (WIP)

[dfort]

Consider updating to latest plug-in version (which includes updated cr2hdr).

First thing I did after figuring this thing out. Everything is working great now.

I was wondering, is the cr2hdr source that is in the bitbucket unified branch the latest 20bit version? It looks like exiftool-bridge.c is where exiftool is being called and it doesn't have an option for a path argument. I suppose that in Windows it look in the current path (inside the plug-in directory) first while on a Mac it will use whatever it finds first the system path (/usr/bin in my case).

[Danne]

Nice work @dfort.
I think mac cr2hdr20bit binary calls for both dcraw and exiftool from /usr/bin/. At least that was my conclusion when I was trying to create a workflow service directing a script to another adress. At least exiftool was problematic to redirect.

[dfort]

Ready for the next issues?

I thought I'd do some Lossless DNG Compression so I selected it in the plug-in's GUI and all of the radio button selections disappeared except for the one I selected.



Closing and relaunching the plug-in GUI restored the radio button selections.

When I compared the file size of the compressed dng it was the same as the uncompressed file. Checking the TXT file I found this:

Code Select Expand

Puerto_Rico_silver_cam-2095-dualiso.DNG
/Volumes/Silver/Pictures/LightroomMasters/2015/2015-07/2015-07-06/Puerto_Rico_silver_cam-2095-dualiso.DNG: copying EXIF from /Volumes/Silver/Pictures/LightroomMasters/2015/2015-07/2015-07-06/Puerto_Rico_silver_cam-2095-dualiso.dn6
Adobe DNG Converter not found.


Note that in the pop up window after the export is finished there is no error message.

(Nit-picky note: the third time the file name is displayed it ends with a lowercase "dn" and the number six.)

Sorry to use up bandwidth on the forum, this is better handled in bitbucket but since development is being done "off the grid" so to speak I thought I'd bring it up here.

[Danne]

Just tried "compress" option which worked but not "compress-lossy".  I have adobe dng converter installed in applications folder. Has to be downloaded externally. I assume you have it installed already? The dn6 I think came with latest cr2hdr20bit. Changes names in process and in the end with .DNG. Also when compressing the file is renamed again since adobe dng converter doesn,t allow overwriting.

[dfort]

Learning something new every day.

Found the latest version (9.1) of the Adobe DNG Converter here:
http://www.adobe.com/support/downloads/thankyou.jsp?ftpID=5914&fileID=5941

Silly me, I thought that it was installed along with Photoshop, Lightroom and Adobe Camera Raw.

Now I'm able to make lossless DNG files that are about half the size of the uncompressed DNG's.

Code Select Expand

Output file     : /Volumes/Silver/Pictures/LightroomMasters/2015/2015-07/2015-07-06/Puerto_Rico_silver_cam-2103-dualiso.DNG
/Volumes/Silver/Pictures/LightroomMasters/2015/2015-07/2015-07-06/Puerto_Rico_silver_cam-2103-dualiso.DNG: copying EXIF from /Volumes/Silver/Pictures/LightroomMasters/2015/2015-07/2015-07-06/Puerto_Rico_silver_cam-2103-dualiso.dn6
Found /Applications/Adobe DNG Converter.app/Contents/MacOS/Adobe DNG Converter
Compressing /Volumes/Silver/Pictures/LightroomMasters/2015/2015-07/2015-07-06/Puerto_Rico_silver_cam-2103-dualiso.DNG...
"/Applications/Adobe DNG Converter.app/Contents/MacOS/Adobe DNG Converter" -dng1.4  -o "Puerto_Rico_silver_cam-2103-dualiso.DNG" "/Volumes/Silver/Pictures/LightroomMasters/2015/2015-07/2015-07-06/Puerto_Rico_silver_cam-2103-dualiso.DNG.DNG"


From the message in the TXT log file it seems that the final file was named to *.DNG.DNG but that isn't the case. The only difference seems to be that instead of 37.6 MB files they are 17.4 MB (give or take) or about the same size as the "original" Lightroom dng files. That's great news because the HDR files created in Lightroom from a three shot bracket set are weighing in at around 73 MB.

I also got the same issue as Danne with compress-lossy.

Code Select Expand

cr2hdr: a post processing tool for Dual ISO images

Last update: 0c08758 on 2015-05-09 19:25:05 UTC by a1ex:
cr2hdr: Makefile commands to create a zip package for Windows

Unknown option: --stripe-fix--compress-lossy

@kichetof and @Walter Schulz - Just a suggestion--add a note about adding Adobe DNG Converter to the plug-in installation instructions.

[DeafEyeJedi]

Wow just digged through the past few pages of fun stuff. Good work @dfort and Thanks to @Walter Schulz & @Danne for their contributions on getting this resolved.

I admit that I have not been using this plugin in LR5 for quite a few months now... Been busy with Video shooting and work has taken my time away from Dual-ISO Photography.

However, I just decided to give it a go with the BETA3 20-bit on my Mac Mini (I downloaded all of the requirements and installed back in Feb 2015) just to be sure and ran through just fine as expected.

Here are some samples of the workflow:

 

 

So it appears that the Metadata did come through since I can still see them with the converted DNG within PS. (or was the issue only directly for LR?)

Thanks for reviving up this thread alive again!

[dfort]

Are you sure? In the Terminal run exiftool on a DNG file before and after running it through cr2hdr and see if the metadata copied over. Also check your version of exiftool.

Code Select Expand

exiftool -ver

If you followed the plug-in install instructions you will have version 9.34 from a_d_'s OSX_cr2hdr package which seems to have an issue with metadata when used on DNG files with the plug-in. Version 9.98 of exiftool fixed that issue for me.

This doesn't affect cr2 dual_iso files.

There is another possibility that I just thought of. The DNG files I was using were using lossless compression and when I was doing these tests I didn't have Adobe DNG Converter installed. In any case we should probably be using exiftool 9.98 instead of an earlier version with this plug-in.

[Walter Schulz]

The DNG files I was using were using lossless compression and when I was doing these tests I didn't have Adobe DNG Converter installed.

Sorry? cr2hdr without DNG converter will produce uncompressed DNG only

[dfort]

The DNG files I was running cr2hdr on were compressed on import to Lightroom. I was reading compressed DNG's not writing them.

I didn't test it because I would have to uninstall Adobe DNG Converter and regress to exiftool 9.34 to see if that was the problem when I first reported the metadata issue. It seems better to continue moving forward now that things are working. I sent a_d_ a PM via bitbucket to ask if OSX_cr2hdr could be updated with exiftool 9.98.

[Danne]

Most likely deafeyejedi got exiftool version from cr2hdr-r installed in usr/bin. Adobe dng converter most likely will not interfere at all with current metadata issues. What would be welcome is to correct the compress-lossy argument. It, s actually useful on still image files and files are greatly reduced in size.

[DeafEyeJedi]

@Danne's correct on that. That's the beauty of his 'cr2hdr-r' app which contains all the updated requirements for the most part thus the reason(s) why this plugin worked fine for me in LR5.

I also agree on the fact that we should definitely try and figure out how to resolve the compress-lossy argument since it is indeed very intuitive for these stills to be greatly reduced in size!

@dfprt: I just ran Terminal to verify my exiftool's version -- came up 9.69 and I guess I should update that to the latest on the MBP? (I'll double check the exiftool's version on my MacMini later tonight after work at home) though I admit it could be 9.69 since it's most likely installed from cr2hdr-r.

@Danne: I'll double check your latest beta app but my gut feeling is that it still uses 9.69 -- perhaps it can be replaced with newer version manually within OX S, right?

*UPDATE*

I just updated Exiftool to latest (9.98) and will try to run Dual-ISO files in LR5 with this plugin on MBP and will report back. Thanks!

[Danne]

Could be correct. Havn, t updated exiftool in a while.

[dfort]

I'm new to dual_iso and was checking out the various tools. Obviously I got hung up on the Lightroom plug-in.

@DeafEyeJedi I just tested exiftool 9.69 and it worked fine with the Lightroom plug-in workflow. In fact I installed 9.69 by removing what I had in /usr/bin and running the cr2hdr-r installer. After the test I put 9.98 back into /usr/bin just because--

@Danne I finally got around to trying out your dualiso_to_DNG Mac services app and wow, so simple and elegant to use. It doesn't even use exiftool and there's no problem losing metadata. I'm also checking into your cr2hdr-r. Maybe this should replace the instructions to use the OSX_cr2hdr package from a_d_ as a simple way to install dcraw and exiftool dependencies for the Lightroom plug-in?

Of course I also agree that the compress-lossy issue would be nice to resolve. Too bad the development for the plug-in is not taking place on the ML bitbucket repository.

Just wondering, does compress-lossy work when using cr2hdr on the command line? The problem may not be in the plug-in.

[DeafEyeJedi]

@dfort: Ah, Gotcha that makes sense! Please continue to play with @Danne's incredible app/service workflow since it works really well for most situations and it actually does all the dirty work as well as organizing files into folders for you. Just simply laid back and enjoy a cup of tea while you're at it or sleep overnight with ease!

Well I am glad you are still hung on using Dual-ISO -- it's one of the best features for ML of all time and definitely takes time getting used to but you're getting closer!

Strange that you managed to get this plugin to work again after downgrading/upgrading the exiftool because for me it was rather strange and I knew I shouldn't have tried fixing what's not broken, right? lol

Anyway so on my MBP after updating the exiftool to the latest and tried running LR5 again with the plugin which now is popping up windows saying "Please report to ML forum. An internal error has occurred: Failed to find a place for the imported file" in which I have tried both with original and new folder but neither worked. I'll have to investigate further why it works on Mac Mini but not the MBP.

and on top of that it's even more odd that both of the Beta3 20-bit plugin's are showing different options to choose from in between my MBP and Mac Mini.



On the MBP it isn't showing the option to choose "KEEP ORIGINAL DNG AFTER CONVERSION" but it does on the very same plugin in Mac Mini, strange?

p.s. Yes, both are running the latest OS X (10.10.1) in case you guys were curious.

[Walter Schulz]

Compare plug-in files. There must be differences

And something we have to settle: Go on with Beta3 linked in first post or updated (latest) files?

[DeafEyeJedi]

@Walter Schulz:

I can't compare the plug-in files until I get home tonight (I let this one slip under my radar by installing 3.0 instead of 3.2). Meanwhile I'll continue to investigate further on making this to work on MBP.

I personally think we should update to the latest file instead of using the links in the first post (You're referring this to the files from  a_d_, correct?)

[Danne]

@dfort.
Compresslossy works fine with cr2hdr20bit binary. It can be tested in my automator workflow. Simply write command straight to one of the files according to instructions in first post. (Off topic)
Wouldn, t advice using my install pack since there is a lot of other stuff but Kichetof could update his first post when he is ready. His lightroom integration is really cool.

[DeafEyeJedi]

Agreed with @Danne about not recommending using his install pack because it has a whole bunch of files that are specifically made in order for his app to run smoothly.

Hopefully @Kichetof would either be busy and reading all of this or he is just simply MIA until then since his LR integration plugin is still a useful tool especially for TL.

*UPDATE*

Sorry guys I let this one slip under my radar -- realized I downloaded Beta 3.0 on MBP when it needs to be updated to Beta 3.2 from this post #616.

*UPDATE 2*

My apologies but I was eager on getting this resolved by then decided to try Dual-ISO files from both EOS-M and 5D3 which spitted out just fine with 3.2 beta BUT then I tried again with the same 70D files which kept giving me the same error I reported earlier (I thought @kitchetof updated his cr2dhr binary just for the 70D recently?) so I am not sure what the heck is going on in here on my MBP but until then... Will have to wait until I get home tonight after work to test this further. It seems to be the 70D files issue but again I'm not too sure yet.

If anyone out there wants to try a 70D Dual-ISO file to confirm if this is not only happening to me, Thanks!

https://mega.co.nz/#!7t8wVBKJ!Udj5CLNekaISLDcGtmtVznbUVGpMeMydYnmb40p3p38

[mylesgray]

Hi Guys,

Seeing some strange behaviour with LR 3 BETA 3 and BETA 3.2 plugins, after conversion my DualISO files exhibit a single pixel line (seems to be the recovery ISO line) on the very bottom edge of the photo.

See attached CR2 and DNG, also conversion output.

https://www.dropbox.com/sh/ow65u37rqajvukh/AAB84YJM-yfw8pymFNdSosBya?dl=0

Is this a known bug or new?

Myles

[dfort]

@mylesgray - Welcome to the forum. I checked out your files and I've never seen that on my dualiso.DNG's so I processed your cr2 file and it came out clean on my system. (Read on for a possible solution.)

@DeafEyeJedi - The Lightroom plug-in development could use some housekeeping but it looks like kichetof is taking a break. The latest version that Walter Schulz pointed me to is here: http://www.magiclantern.fm/forum/index.php?topic=11056.msg147298#msg147298 It looks like you already grabbed it a while ago but maybe it only got on one of your computers? This version only uses the cr2hdr 20bit version and you should see just one cr2hdr options tab on the plug-in GUI.

If anyone out there wants to try a 70D Dual-ISO file to confirm if this is not only happening to me, Thanks!

I tried it on my system and it worked fine.

@Danne I understand your point about not wanting to have someone install your package in order to get the dependencies for another developer's work. In fact all of the dependencies for the plug-in are inside of the plug-in package but because of the way things are set up on OS-X it uses the exiftool and dcraw that are installed on the system--specifically /usr/bin. At least I found out that when cr2hdr calls exiftool there is no option to specify the path to exiftool (exiftool-bridge.c).

[DeafEyeJedi]

@mylesgray: Likewise and also confirmed that it spitted out just fine with your file.

@dfort -- Thanks for confirming that the problem is ON ME in particular with this MBP and not the 70D files ( which I figured it would be ) because I have used this plugin with 70D files before on MacMini after he released 3.2 BETA.

I'm still not quite sure what the problem could be but I've tried reinstalling the exiftool and dcraw but it stills doesn't work with 70D files on my end.

All other camera's Dual-ISO files do spit out just fine. Not much for me to do until I get home tonight after work to compare MBP with MacMini.

[Danne]

@dfort. Do you have any idea where the compress-lossy argument is called from in the plugin? If that is fixed it would be very nice.

[DeafEyeJedi]

@dfort. Do you have any idea where the compress-lossy argument is called from in the plugin? If that is fixed it would be very nice.

Same here. Please let us know asap. Thanks!

[dfort]

@DeafEyeJedi @Danne Quick enough for you guys? I got to take a break from my keyboard!

It looks like the default settings and where the options are passed are in MLExportServiceProvider.lua and the file that selects the "--compress-lossy" is in MLProcess.lua.

I ran a compress-lossy test and checked the Console to see what arguments the plug-in was passing:

Code Select Expand

7/15/15 3:25:40.500 PM Adobe Lightroom[511]: MLDualISO DEBUG command : exec "/Library/Application Support/Adobe/Lightroom/Modules/cr2hdr.lrplugin/bin/cr2hdr" --amaze-edge --cs2x2 --no-bad-pix --fullres --alias-map --stripe-fix--compress-lossy --wb=graymax "/Volumes/Silver/Pictures/LightroomMasters/tests/IMG_9584-dualiso.dng" > "/Volumes/Silver/Pictures/LightroomMasters/tests/IMG_9584-dualiso.TXT"


It looks to me that the issue is in "--stripe-fix--compress-lossy" note that there is no space between these arguments.

*UPDATE*

Found the problem. In MLProcess.lua change this line:
exportSettings.compress == 1 and " --compress" or ((exportSettings.compress == 2) and "--compress-lossy" or ""),

Add a space at the first quote of --compress-lossy so that it looks like this:

Code Select Expand

exportSettings.compress == 1 and " --compress" or ((exportSettings.compress == 2) and " --compress-lossy" or ""),

Now compress-lossy works.

Big difference in file size, the file I tested went from about 20 MB (lossless compression) to 5.3 MB.

[Danne]

Awesome!