Wow, this is music to my ears! Of course I don’t expect anything to happen quickly (or maybe even at all), but if this does go ahead I’ll be first in line to test.
Apologies to everyone for going offtopic - although this could be used to try out these tone curves too
@ggbutcher Yes please! One request is to allow us to update the gmic binary itself. I was happy when PhotoFlow finally included G’MIC but the issue was I couldn’t change the dev gmic core as I saw fit. You see, David makes a lot of bug fixes and changes.
Glad you spoke up, I wasn’t heading that way. Was planning to use libgimc and to marshall rawproc RGBs into and outof the G’MIC internal format…
I mean, it’s pretty simple, save the internal image to a 16-bit tiff, use the system() call to run gmic ‘somescriptfile’ and read back in the resulting whatever result was generated and go on from there in the rawproc toolchain. I already have code to run externals (exiftool) and to read/write tiffs to/from the internal representation, so, easy-peasy… ??
I’ll do a quick-n-dirty implementation, then take feedback from any who try it. I’ll probably have something mid-next-week; I’ll start a new thread to announce the branch and for discussion.
That is also a valid solution, because you also keep G’MIC up-to-date just by updating libgmic.so.3 as a new G’MIC release happens.
That’s very similar to other things I’ve done with libgmic in the past and it does work well. In fact, I wrapped a wxwidgets GUI around it, with a text editor for the code. Sure, you could go the whole g’mic GUI approach, but I think code into the std lib fits the spirit of rawproc.