Lightroom plugin cr2hdr v3.0 DEV (WIP)

Started by kichetof, March 18, 2014, 05:04:33 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

dfort

I got something even quicker.

Open the terminal and add the path to the plugin's bin directory ahead of the system path.

export PATH="/Library/Application Support/Adobe/Lightroom/Modules/cr2hdr.lrplugin/bin":$PATH


Then simply start Lightroom from the terminal. Well maybe not so obvious:

/Applications/Adobe\ Lightroom/Adobe\ Lightroom.app/Contents/MacOS/Adobe\ Lightroom

The terminal has to be left open or LR will shutdown. You can also geek out at the messages LR outputs.

Sorry, I would have told you sooner but I just thought of this. In any case, these are just workarounds, the plugin should still be fixed.

dfort

Until a real fix is found I uploaded a version of the cr2hdr.lrplugin that has the latest cr2hdr, dcraw and exiftool installed internally. This should be fine with Windows and Mac--pre El Capitan. If the Mac version can't find dcraw and exiftool it will display a dialog box with instructions on how to set the path with the terminal and how to launch LR from the terminal so the plugin works.

Here's the download link to all things cr2hdr that I compiled on October 1. Note that they should be replaced once new "official" versions are ready.

[EDIT: Official version is ready: https://bitbucket.org/kichetof/lr_cr2hdr/downloads ]

wadehome

Or my method is a permanent fix. But it means low level Mac editing. It's not ideal but it saves launching Terminal every time.

Danne

@Wadehome. Did you run the install for usr/bin or usr/local/bin?


wadehome

@Danne I just ran the normal install which puts them in usr/bin, but you need to make sure you disable system integrity first.

dfort

@wadehome -- The reason I'm trying to get the dcraw and exiftool that is already inside the plugin working is because:

  • Easier installation.
  • Some users may not want to mess around with changing the security of their systems or might not have administrative access if using a computer in a corporate environment.
  • dcraw and exiftool are regularly updated and if the they are installed with package managing systems like MacPorts and Homebrew they tend to lag behind on releases--sometimes way behind.
  • Updating the plugin will automatically update dcraw and exiftool.
  • The user can have custom built version of these programs without interfering with the ones in the plugin. For example dcraw can be configured to work with RED Camera raw files.
  • Finally, they are already inside the plugin and Windows uses them so the Mac should behave the same way.
In the meantime it is very easy to write a simple shell script that can launch Lightroom with the proper path for the plugin. Open TextEdit and copy and paste from the dialog box (using the version I uploaded last night). Just make sure to save it as a plain text file and add a ".command" file extension. For example on my system it looks like this:

LR.command
export PATH="/Library/Application Support/Adobe/Lightroom/Modules/cr2hdr.lrplugin/bin":$PATH
/Applications/Adobe\ Lightroom/Adobe\ Lightroom.app/Contents/MacOS/Adobe\ Lightroom


In order to get it to launch by double-clicking you need to go to the terminal and enter this:
chmod +x LR.command

Note that you don't have to cd to the file location to do this. Simply type chmod +x then drag and drop the file into the terminal window to get the path to your file.

Like I said this is just a workaround until someone comes up with a way to get the lua script inside the plugin to find the path to dcraw and exiftool that are located inside the plugin. Or maybe cr2hdr needs to be modified so it can accept a path argument?

dmilligan

So I tested it out, and it is as I suspected, environment variables are not persisted to the next call to LrTasks.execute().
Test Code:

  LrTasks.execute("echo ======================")
  LrTasks.execute("export PATH=/my/test/path:${PATH} && echo ${PATH}")
  LrTasks.execute("echo ======================")
  LrTasks.execute("echo ${PATH}")

Output:

======================
/my/test/path:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/git/bin:/usr/local/astrometry/bin:/usr/local/opt/coreutils/libexec/gnubin
======================
/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/git/bin:/usr/local/astrometry/bin:/usr/local/opt/coreutils/libexec/gnubin


But this is no problem, all you have to do is prepend the path export to all the calls to cr2hdr, which should be very simple (and get rid of the dependency check like you already have).
For example, simply replace all the lines:

result = LrTasks.execute(command)


with this:

if MAC_ENV then
    command = 'export PATH='..LrPathUtils.child(_PLUGIN.path, 'bin')..':${PATH} && '..command
end
result = LrTasks.execute(command)


dfort

I was just about to report on a suggestion I got on the Adobe Lightroom SDK forum. Their top guy there, johnrellis, confirmed that LrTasks.execute() calls don't persist. What he suggested is to make a launcher script for cr2hdr. Basically it does the same as what you are suggesting, set the path just before launching cr2hdr.

cr2hdr.sh
export PATH=`dirname -- "$0"`:$PATH
cr2hdr $@


I like your approach better. I've got to take a break now--it is Friday night here and I'm getting pulled away from the keyboard.

[EDIT: By the way I did do exactly what you suggested, there were only 2 "result = LrTasks.execute(command)" in the script but it didn't work. Looks like it is going to take a little longer to fix this.]

dfort

One more try and it worked!

The path had spaces so it needed to be in quotes. Notice the quotes after the ="' and 'bin"'

if MAC_ENV then
    command = 'export PATH="'..LrPathUtils.child(_PLUGIN.path, 'bin"')..':${PATH} && '..command
end
result = LrTasks.execute(command)


Big thanks to dmilligan!

[EDIT: Official version is ready: https://bitbucket.org/kichetof/lr_cr2hdr/downloads ]

dfort

There's still more to do.

The Mac GUI issue I reported back in July should be solved and if you choose make a compressed DNG without having the Adobe DNG Converter installed it will give you an uncompressed dualiso.dng but no warning that it could not compress the DNG. The only indication that something went wrong is if you have the log file option enabled there's a little note at the end of the file, "Adobe DNG Converter not found."

The "proper" way to deal with this is through kichetof's bitbucket repository but he hasn't been active for a while. Anyone near Geneva, Switzerland who could bribe him with some beer?

dfort

Taking a closer look at the GUI, wb=exif is being cutoff. This shows up on two Macs that I have tried. In addition, the window cannot be resized to show it properly.


I made a fix of this in case anyone else is having this problem. In addition I forked kichetof's repository and will start doing the changes there so my test builds will be located at:

[EDIT: Official version is ready: https://bitbucket.org/kichetof/lr_cr2hdr/downloads ]

Please test out the WIP build and post feedback.

Hope this doesn't cause too much confusion. As far as I know kichetof is the only one who can make changes to the plugin's official bitbucket repository. While we're waiting for him to come back to this project you can check out his photos on Flickr.

Danne

Nice to see this plugin maintained Dfort.

DeafEyeJedi

Indeed it is nice to see this plugin maintained.



Great work & Thanks, Daniel!
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

dfort

Need some feedback from Windows users.

Are the radio buttons disappearing when you select a radio button. Look at the screenshot of the Mac UI to see what I mean.

I've been in contact with Adobe about this. Looking for a workaround.

https://forums.adobe.com/message/8030703#8030703

Walter Schulz

No, they don't disappear. Kichetof had the same problem and it was discussed here before.

dmilligan

perhaps you should just use dropdowns instead of radio buttons, that will make it a lot more compact anyway

dfort

Yes it was discussed before but things are changing and just wondering if that has changed too.

I grouped the radio buttons and it is working but it doesn't look too good:


Got a few suggestions including the dropdown (popup_menu?) and using os_Factory so it looks like there's a few things to try out.

Walter Schulz

Just retested it with yesterdays build. All radio buttons are persistent.

dfort

Posting another work in progress - cr2hdr.lrplugin_2015-10-05_WIP.zip This is for Mac users who are bothered by the disappearing radio buttons.

An hour ago I had enough fun for the day and posted a less than ideal version but I gave it one last try and it worked. So it looks exactly like kichetof designed it but the radio buttons don't disappear on the Mac. I could use some feedback from Windows users to make sure nothing is broken on that side.

I'll post the build here as soon as I clean up the code:

[EDIT: Official version is ready: https://bitbucket.org/kichetof/lr_cr2hdr/downloads ]

Walter Schulz

First link not working, second link only showing "download repository" with older build -> Unable to test newest build.

dfort

Hi Walter Schulz, you're too quick for me. It took me longer than I anticipated but it is there now. Replaced in both repositories. Also made a pull request. Hope I didn't break anything.

Walter Schulz

Had to wait for LR update. Slow line here.
Windows GUI looks good so far. Will test conversions later. And welcome back, kichetof!

dfort


nikfreak

[size=8pt]70D.112 & 100D.101[/size]

Danne

Worked prefectly both with lightroom plugin and cr2hdr-r @Nikfreak :).