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.

camagna

I really hope that some of you can solve the issue because I'm on 10.11 and I need to process a lot of files from an assignment. I'm really stuck now.  :(

Danne

You could try install the binary pack from app cr2hdr-r since it places both exiftool and dcraw in usr/bin through a script.

wadehome

Quote from: camagna on September 29, 2015, 06:03:08 PM
I really hope that some of you can solve the issue because I'm on 10.11 and I need to process a lot of files from an assignment. I'm really stuck now.  :(
I'll do my best to do a temporary work around but if I can't, you could upload the files to Dropbox and I could just do it on my Windows computer for you.

Quote from: Danne on September 29, 2015, 06:12:35 PM
You could try install the binary pack from app cr2hdr-r since it places both exiftool and dcraw in usr/bin through a script.

That's the whole issue; I have tried that many times, it says that it has 'installed' but if you go to usr/bin the files aren't there due to 10.11 not allowing that folder to be modified. Even through Terminal (command line) to just copy them there, it doesn't allow that. To use the non-Lightroom processing app on Mac always fails to work as well.

dmilligan

Quote from: wadehome on September 29, 2015, 05:20:53 PM
I'll see if I can edit cr2hdr to not look to OSX/not look to /usr/bin for the exiftool and dcraw. Probably impossible but I'll see what I can do.
cr2hdr simply calls 'exiftool' and 'dcraw'. This means that OSX simply uses the PATH environment variable to resolve their locations. They do not have to be in /usr/bin, they can be anywhere that is on the PATH. /usr/local/bin is on the PATH, and that folder is not restricted by 10.11's new rootless "feature" (this is what dfort suggested doing). Additionally, you can simply put them anywhere you want and add that directory to the PATH (environment variables are specific to the local user, you don't even have to be root to change them, because they are *your* environment variables). If you want to have them in the plugin folder so they don't have to be "installed" somewhere, simply have the Lr plugin modify the PATH to include the plugin's bin directory.

I think something like this should work:

LrTasks.execute('export PATH="${PATH}:'..LrPathUtils.child(_PLUGIN.path, "bin")..'"')


You can also simply using something like homebrew to install these:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install exiftool
brew install dcraw


BTW, there's some good information about SIP and how it affects /usr/local/ on hombrew's github, here: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md


@Danne, you should probably update your cr2hdr-r installers to use /usr/local/bin/ for compatibility with 10.11

Danne

Thanks for info. I, ll check in to that usr/local/bin instead.

Danne

I updated cr2hdr-r with the /usr/local/bin folder. I tried many scenarios, seemed to work but please check and report if testing. Binary pack will all move to /usr/local/bin now.

dfort

Quote from: dmilligan on September 30, 2015, 03:18:16 AM
I think something like this should work:

LrTasks.execute('export PATH="${PATH}:'..LrPathUtils.child(_PLUGIN.path, "bin")..'"')


Cool, I was searching all over the place for this. I was thinking of putting it either in this function:

MLProcess.lua
-- Check for Mac dependencies
function MLProcess.checkDependencies()
    return "exec which dcraw exiftool"
end


or just before calling that function:
    if MAC_ENV then
        local cmd = MLProcess.checkDependencies()
        isDependOk = LrTasks.execute(cmd)
        if isDependOk ~= 0 then
            LrDialogs.message(LOC "$$$/ML/Dependencies/ErrorTitle=~ Dependencies error ~", LOC "$$$/ML/Dpendencies/Error=This plugin (cr2hdr) need dcraw and exiftool.^n^nPlease install it before run this plugin")
            do return end
        end
    end


So it will find the dcraw and exiftool that is installed in the plugin's bin directory on the Mac.

It looks like Windows looks in the plugin bin directory before searching the environmental variable path. That would be the preferred behavior on Mac too.

dmilligan

Quote from: dfort on September 30, 2015, 07:32:49 AM
It looks like Windows looks in the plugin bin directory before searching the environmental variable path. That would be the preferred behavior on Mac too.

The default behavior of Windows is that the current directory is automatically included (first) when searching the PATH.

So on Windows you can cd to a directory containing an exe and call it simply using it's name (e.g. myexe). On mac (and other *nix OSs) you can't do this, if you want to execute something that's in the current directory you must specify it's path, the easiest way is with "./" so for example: ./myexe


There is one assumption my solution makes and that is that the state of environment variables are maintained from one call to LrTasks.execute() to the next. If this isn't the case (I'm not really sure if it is or not, you'll just have to try it) then you may have to make it into one single command to set the PATH and call cr2hdr.

dfort

Quote from: dmilligan on September 30, 2015, 01:00:59 PM
There is one assumption my solution makes and that is that the state of environment variables are maintained from one call to LrTasks.execute() to the next. If this isn't the case (I'm not really sure if it is or not, you'll just have to try it) then you may have to make it into one single command to set the PATH and call cr2hdr.

One thing that I tried as a test before I saw your post was to remove dcraw and exiftool from their installed locations add the plugin's bin directory to ~/.profile
## LR Plugin Test
export PATH="/Library/Application Support/Adobe/Lightroom/Modules/cr2hdr.lrplugin/bin:$PATH"


It worked from the terminal:

$ which dcraw
/Library/Application Support/Adobe/Lightroom/Modules/cr2hdr.lrplugin/bin/dcraw


but as I'm posting this the plugin reports "~Dependencies error~" and now I can't restore things to their former working condition -- can't make sense of this.

dmilligan

You might want to take out the dependency check altogether (if this works, you theoretically won't need it anyway)

dfort

Ok--this hasn't been easy but I'm starting to get the hang of it.

Removed the function to check for dependencies and modified the section that calls that function and displays the error message to this:

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


This doesn't work as desired yet. If dcraw and exiftool are installed on the system it will still work but only because it finds them in the path but not the ones in the plugin's bin directory. Removing dcraw and exiftool from /usr/bin or wherever will break the plugin (of course no error message). However, the file (or database?) is modified so that the image should be deleted and reimported for the next test--that is something that took me a while to figure out. Note that without dcraw it errors out but if only exiftool is missing it will complete the conversion without an error message but also without the metadata on the converted file. This may be obvious, just reporting what I observed.

So it is not finding dcraw and exiftool in the plugin's bin directory yet. In addition, shouldn't the "_PLUGIN.path" be searched before the system path? If there is a different version of dcraw and/or exiftool installed in the system it might create unexpected results.

Like this?

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


Thought that isn't working yet either.

dfort

Wrote a shell script that is promising.

path.command
#!/bin/sh
export PATH=./bin:$PATH


Rosies-Air:cr2hdr.lrplugin Fort$ which dcraw
Rosies-Air:cr2hdr.lrplugin Fort$ source path.command
Rosies-Air:cr2hdr.lrplugin Fort$ which dcraw
./bin/dcraw


But I can't seem to find a way to run this from the plugin:
    if MAC_ENV then
--      LrTasks.execute('export PATH="..LrPathUtils.child(_PLUGIN.path, 'bin')..":${PATH}')
      LrTasks.execute('source path.command')
    end

dmilligan

I would use full paths for everything and not make the assumption that cwd is the plugin path (I have no idea if this is the case or not, it might be). You have _PLUGIN.path available, so just prepend it to all your paths. Also not sure why you are putting it in a shell script, doesn't seem necessary, it's a one liner anyway.

My concern is that environment variables you set are not persisted from one call to LrTasks.execute() to the next (again, I have no idea if this is the case), which would mean you need to set the path and call cr2hdr all at once.

dfort

dmilligan -- You're post came in while I was writing and testing this out. I was testing this on a shell script simply because I know it better than Lightroom's version of lua. Of course you are right that it should all be done in lua. In any case, this is what I found out--

Made some discoveries but still not working.

The plugin looks for all executable files in the bin directory so I moved the shell script in there. I also changed it so instead of creating a relative directory it will define an absolute path:

bin/path.command
#!/bin/sh
export PATH=$PWD:$PATH


Rosies-Air:bin Fort$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Rosies-Air:bin Fort$ which dcraw
Rosies-Air:bin Fort$ source path.command
Rosies-Air:bin Fort$ echo $PATH
/Library/Application Support/Adobe/Lightroom/Modules/cr2hdr.lrplugin/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Rosies-Air:bin Fort$ which dcraw
/Library/Application Support/Adobe/Lightroom/Modules/cr2hdr.lrplugin/bin/dcraw


So now the plugin launches and runs but it still doesn't process the file so maybe the new path isn't available to the plugin?

I also did some experimenting placing dcraw in various path locations and it seems that it is only available when it is placed in one of the factory default path locations:

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

This might have been a part of a security update when Apple pushed out 10.10.5.

dmilligan

Have you tried what I suggested: doing the path setter and cr2hdr in one single call?

e.g.

LrTasks.execute('export PATH=<blah blah> && cr2hdr <args>')

dfort

I see, so if the path settings don't persist and cr2hdr, dcraw and exiftool need to have absolute paths to launch properly--it looks like I'm working on the wrong section of the lua script. I'm getting the feeling that there was a recent change to the way applications use the path variable because the macports installation in /opt/local/bin stopped working with the LR plugin even though it was still available through the terminal.

This is a moving target. While I was working on this Adobe updated Lightroom and Apple released El Capitan, OS-X 10.11, today. My system is updating now so we'll see what surprises that brings.

dfort

dmilligan -- made a pull request on your branch of cr2hdr20bit. As long as everyone else is updating--using the latest versions of cr2hdr, dcraw and exiftool. It all works as long as dcraw and exiftool are in /usr/bin but still need to get them working inside the plugin directory structure.

[EDIT - Never mind, the system finished updating so I switched to a plugin before I started hacking at it and I'm back to where I started with the dependencies error even with the tools installed in /usr/local/bin. Oh, and /usr/bin is now off limits.]


wadehome


dfort

Quote from: wadehome on October 01, 2015, 10:16:12 AM
So, we haven't gotten anywhere then?

You said that you have a Windows system? The same plugin you have installed on your Mac should work on Windows. It is just OS-X, specifically 10.10.5 and 10.11 that seem to be a problem.

wadehome

I do since i have dual booted my Mac, but it's still a pain as I'm only using the standalone program because I'm currently in Bali and haven't had a chance to download Lightroom to the Windows boot, so I was just checking if we had made any progress on the 10.11 issue. I have been able to redirect Lightroom with some trick aliases but it only worked until I quit Lightroom.

dfort

I spent the last couple of days trying to figure this out. Ideally the plugin will work without needing to have dcraw and exiftool installed on the system because they are already inside of the plugin. I've got a couple of Macs, both updated to 10.11 and even with dcraw and exiftools in /usr/local/bin the plugin doesn't work.

Rosies-Air:bin Fort$ which dcraw exiftool
/usr/local/bin/dcraw
/usr/local/bin/exiftool


Although dmilligan's suggestions look correct according to the Lightroom SDK 6.0 documentation, I couldn't get it to work. Looking into kichetof's code it seems he went to great lengths to get LrTasks.execute commands to a single variable name. I ended up building up the command to set the path in several small steps and kept checking the code with a LrDialogs.message but even though everything looks good, including the quotation marks needed because there might be a space in the path, it still doesn't work.

    if MAC_ENV then

        local exportPath = 'export PATH="'
        local toolsPath = LrPathUtils.child(_PLUGIN.path, 'bin"')
        local searchPath = exportPath..toolsPath
--        LrDialogs.message(searchPath)
        LrTasks.execute(searchPath)


The searchPath variable ended up like this on my system:
export PATH="/Library/Application Support/Adobe/Lightroom/Modules/cr2hdr.lrplugin/bin"

Don't know where to go from here.

[EDIT: Doh! I thought it wasn't necessary to append the system path but I just checked it out and and of course all of the system tools are in /usr/bin. Looks like I've got more work to do.]

wadehome

I fixed it on 10.11.... so so so so so easy....

dfort

Would you share please?

BTW--adding the system path at the end works great in the terminal but doesn't work at all in the plugin. Maybe I've got other issues. (Yeah, laugh.)

Just for the record:

    if MAC_ENV then

        local exportPath = 'export PATH="'
        local toolsPath = LrPathUtils.child(_PLUGIN.path, 'bin"')
        local systemPath = ':$PATH'
        local searchPath = exportPath..toolsPath..systemPath
--        LrDialogs.message(searchPath)
        LrTasks.execute(searchPath)


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

which finds the tools installed in the plugin first then goes to the system for anything else--at least that's the way it works in the terminal. Plugin is still broken.

wadehome

It's temporary but it works:

1. Restart the computer, while booting hold down Command-R to boot into recovery mode.
2. Once booted, navigate to the "Utilities > Terminal" in the top menu bar.
3. Enter csrutil disable in the terminal window and hit the return key.
4. Restart the machine and System Integrity Protection will now be disabled.
5. Run install from cr2hdr package to install the files.
6. (optional) To reenable System Integrity Protection follow the steps above, except use the csrutil enable command for step 3.

It doesn't change the plugin, but it does allow us to use it as per normal again, and takes a matter of minutes to do.