marshall rawproc internal image into a gmic_image,
mung it up with a gmic() call,
then marshall the result gmic_image back into rawproc internal.
Easy-peasy, as they say, but then @afre pipes up and says he’d really want to be able to use the external gmic executable. Okay, easy-peasy too, just:
export an image file,
use wxcmd (this is a simple single-command shell I wrote for batch processing) to run gmic with the specified image operations, then
read back in the resulting image file and delete those temporary files.
Kinda clunky, but it removes a whole bunch of compilation and linking angst. So, I set out to do this first…
Soooo, what follows is a bit of stream-of-consciousness that engaged me all last evening and this morning. Summarized here:
I really like the libgimc approach. Very clean within the rawproc pipeline, if you respect:
the rawproc 0.0-1.0 black-white range in your G’MIC scripts.
the embedded color profile of the input image, meaning that if the G’MIC script changes the gamut of the image, the embedded profile has to be removed from the rawproc result image data.
If the G’MIC script changes the image organization, e.g., demosaics it, the metadata item Libraw.Mosaiced needs to be changed also. I just incorporated an “edit metadata” dialog to do these sorts of things, so okay…
I really like the external executable approach. Much simpler to manage rawproc’s build configuration. Not sure about the three “respects” in the libgmic consideration above. And now, and this came to me after a bunch of thinking about how to implement such, that it could be a good way to support using ANY scripting program, ImageMagick comes to mind.
So, here’s what I’ve come to in an initial consideration of all this:
rawproc will get a ‘gmic’ tool, and that tool will support the libgmic interface
rawproc will also get a ‘script’ tool, and that tool will support any scripting program that’ll allow a command line of the form:
Okay, I have an initial implementation of a gmic tool. Pretty simple at this point, it reads a script file and uses libgmic to apply it. Acts just like a first-class rawproc tool, and can be inserted anywhere in the toolchain.
I tested it with a simple G’MIC script, mul 2 resize 50%,50%. Keep in mind that the data presented to the script has values in the range 0.0 - 1.0; I added an output gmic.jpg to see what would happen; libgmic still returns the modified image, and it saved the JPEG but there were only a few values in it >= 1…
@afre, I haven’t forgotten you; I’m going to spend a little time designing a script tool that will work with G’MIC and others…
Edit: almost forgot, you need --enable-gmic in your ./configure to expose the code to the compiler. The autoconf will search for an installed library and header file, or you can specify paths with GMIC_CFLAGS and GMIC_LIBS.
I’d like to get it to auto-process based on notification of file modification, wxWidgets watcher will only do directories, so I have to figure that out…
I’m not inclined yet to include a text editor, thinking most have their favorite, but I may put in a small text box for quick-n-dirty coupla-op scripting…
So, I’ve looked into the various ways rawproc can link the libgmic library, and here’s what I have;
Static linking can be done with a direct reference to libgmic.a, this is what I’m currently doing in Windows MSYS2. You can compel rawproc to do this by adding GMIC_LIBS=/path/to/libgmic.a in your configure invocation. You’ll probably also need to do GMIC_CFLAGS=/path/to/gmicincludes . The downside of this scheme is that you need to re-link rawproc every time you compile libgmic.
Dynamic linking is the way to go here, and will require you to install gmic with ‘sudo make install’, but keep in mind G’MIC Makefile installs to the system directories. I think that’s probably ok, as one probably only wants one copy of G’MIC floating around and some distros require user gymnastics to add /usr/local to the LD_LIBRARY_PATH. Just keep in mind that if you’re going to compile G’MIC you need to work out possible conflicts with a distro install.
Latest commit: auto update, when script file is changed. Alleviates the need to hit the Update button when changing a script, just save it and rawproc gmic will autmatically run. Toggle on/off with a checkbox.
I think that’s all I’ll do on it for right now. This week, I’m going to start work on the script tool, but you won’t see it in the repo until next week…
Thanks for the updates, I’m watching this closely
Will try building soon, since I’m doing some of that lately anyway…
Edit: ha, autotools - I don’t envy you supporting that on windows. Maybe things have moved on, but when I learned about it years ago it was painful. This should make it easier for us users though!
Let me know if you hit a roadblock with rawproc. It’s not the easiest thing to build, given its dependence on wxWidgets 3.1. Although, the wxWidgets folk have made it fairly easy with the wx-config script… The Readme at github should really get you through.
Well, I nearly got it working but I’ll have to give up for today. I can select a script file, but nothing changes (I simply added mirror x). At least I got the g’mic options:
I had to modify two lines in rawimage.cpp to RawProcessor.imgdata.params.shot_select instead of RawProcessor.imgdata.rawparams.shot_select to get it to build.
Also had to manually update the linker cache after installing librtprocess. I probably did something dumb along the way. There are a lot of assertion failures pop up too.
Those two lines in rawimage.cpp were changed, I thought. I’ll take a look…
The assertion failure pop-ups are likely your wxWidgets version. When I tried 3.1.5, I got them, reverted back to 3.1.4 and they went away. Not sure if they’re my code or GTK…
I’ll try to be more useful at the weekend, you’re clearly going to need more info. I could probably debug it myself. I have already committed to other things though!
Oh, just remembered: libraw changed the locations of a couple of fields in the latest snapshot, so I changed rawimage.cpp to conform. If you’re using a distro libraw, you’ll have the old definition…
I just merged the gmic branch to master, after working through some autoconf shenanigans - G’MIC library doesn’t include a libgmic.pc, so manual ways of finding the lib were needed… Yeah, cmake one of these days…
Also, I committed a change that commented out all references to libraw’s shot_select variable. LibRaw devs just decided to move it from one ABI-exposed struct to another in the latest snapshot, Geesh… rawproc used it in the dcraw processing option set, which I’m about ready to deprecate anyway. So @garagecoder, you can just re-checkout rawimage.cpp and all should be good there.
Did all your commits definitely get pushed? I still had to edit those lines in rawimage.cpp for some reason. Sadly still no luck with the gmic script actually doing something either - ldd does show rawproc linked to the libgmic.so.3 though.
Edit: also think there’s something going on with wxwidgets build, it’s spamming those assert fails. Still waiting for the weekend before I can really dig, sorry
Cripes, I did a few other changes, forgot to commit that one. It’s there now…
Hmm, strange, I spent a little time this morning applying various transforms, worked like a charm. Nothing more than two lines, though, although I can’t image what that’d have to do with it.
Yes, those asserts are problematic, couldn’t find anything on it in the wxWidgets issues a few weeks ago, so it may be something with how I’m using something… I might do a special link back with 3.1.5 to see if anything pop out…
FYI this is with wx 3.1.4, I actually began with 3.1.2 (linking with wx-config, not installed)
Also, I would bet on this being user error, really I need to either debug it or start spitting out logs…
I found two issues: I had to use wxFileName::MakeAbsolute() and GetFullPath() to ensure the file was actually read. Then I had to remove all newlines, otherwise the script was read as mirror x\n and just didn’t work.
I’m probably doing something extremely dumb, but maybe that helps protect against user stupidity…
