Hi Danne -- excellent work and exciting to see active development in action.
I took a look at cr2hdr-r a few months ago but at the time I was only using dual_iso for still images and I was also learning how to use Lightroom so I decided to go with kichetof's Lightroom Dual ISO Plugin. Now I'm looking into shooting a project in raw video so I'm trying to figure out a workflow to deal with the MLV files and whoa! I'm confused by the sheer number of options available. Of course everyone seems to have their opinion on which is the "ideal" workflow.
Revisiting your project I'm also finding it somewhat confusing because it is not only for dual_iso but it also encompasses raw video, export to ProRes, LUTs, etc. I'm sure this all makes perfect sense to you and other users who have been following your project but I've already run into issues trying to install the command line tools your project depends on. For example, in your source code you have:
/usr/bin/enfuseMac users should be aware of the restrictions that the latest OS, "El Capitan" is putting on where files can be installed and /usr/bin is now off limits. There are ways to work around this but maybe we should ask ourselves if defeating these new Apple policies is something that we really want to do in order to get things working as they used to. The flip side of that argument is that Apple is doing things wrong because OS-X (a.k.a. Darwin) is a Unix type of system and
"The UNIX Philosophy" is to work with a bunch of small programs installed on the system each doing a specialized task, the output of one piped into another and rely heavily on shell scripts to glue them all together. So, why not have it both ways? It seems that it would make everything much simpler if all of the dependencies are bundled inside of the app so the user doesn't have to install half a dozen apps in various directories.
I heard of issues regarding "El Capitan" even before updating my system. A cr2hdr Lightroom Plugin user was on a location job and the system update broke the plugin. It seems that not only was /usr/bin off limits but the plugin couldn't use anything that was installed in /usr/local/bin either. I was asking for a while why was it that the dependencies for the plugin were included in the package but the Mac couldn't utilize them. By the way, Windows did use them so the plugin had to have different installation instruction for Windows and Mac. I started playing around with the code (Lightroom plugins are actually written in lua) and with the help of dmilligan and johnrellis at the
Adobe Lightoom SDK forum the plugin now works the same on Windows and Mac without the user having to install any dependencies--well, except for maybe the Adobe DNG Converter for compressing DNG's.
The trick (by dmilligan) we ended up using in the plugin looks like this:
if MAC_ENV then
command = 'export PATH="'..LrPathUtils.child(_PLUGIN.path, 'bin"')..':${PATH} && '..command
end
result = LrTasks.execute(command)However I was also experimenting with a shell script (suggested by johnrellis) that would probably work for this project.
PATH=`dirname -- "$0"`:$PATH
cr2hdr $@That just might be a fancy way of adding the current directory (represented by a single dot) to the path but it should persist through the rest of the terminal session. On the Lightroom SDK the path setting doesn't persist and needs to be used every time a call is made to cr2hdr. I would try this out on your project but since you don't have your source code on a distributed version control server (like bitbucket.org which is used on most Magic Lantern projects), it makes it rather difficult to submit suggestions (a.k.a. pull requests) to your project.
FYI to the readers of this topic, Danne and I have been sending PM's back and forth and helping each other out but we believe that this conversation might be best done on the forum so anyone can chime in. After all, this is an open source project and user input is not only welcome but encouraged.
