Most kind of you to take the time, mean it
I’ll do buffer/clonning as you say =)
There are a couple different matters about the presset complexity.
One is the limitation(s) of (any) platform. IMO luminosity masks or HSL qualifiers and “merging” ability /// and LUTs /// would reduce the layer count. I’ve done simillar WFs in many apps; e.g. gimp with gmic’s dream smoothing where layers flattern from visible, yet I’m not able to create a macro for it. And that’s another issue, if you flattern the layers any presset’s invalidated as a one step repeatable solution. In that sense I think that despite this being a valid presset (regarding the aeshetic result if one will), it totally fails to be practical within the platform that hosts it; took PF like an hour to procces and export this image, the horror the horror
On the other hand is user handling, in this case me. Maybe I’m spolied in my ways but nevertheless it’s also true I’ve got a tendency to develop quite complex structures. For instance, when I’m grading in davincy it is easy for a single shot to have 20 nodes through out complex pararell and mixing techniques; normally though, I’ld merge those regarding luma and chroma without masks into a LUT and then things become simpler and of course create families (groups) that automatically sync and memories that can be “pasted”… so in the end after dealing and creating an approach for the hero shot, things speed up exponentially. I wont even go into PS, because despite I think it’s quite interestiing to learn from stablish platforms I’m affraid of the witch hunters {rockabilly steam punk score}
I really like photoflow and having in mind its limitations and particularities the question I post myself is how do I go about creating pressets for PF?
That’s me own homework
This is of course not acceptable, and gives me a good test case for checking where things can be optimized…
In fact, luminosity masks are already possible in PhF. There are at least two possible ways to introduce a luminosity mask:
adding a clone layer inside a mask, selecting as input the layer from which you want to get the luminosity, and then add a curves layer to adjust the luminosity range
adding an HSL mask layer inside a mask, and adjust the L curve
Concerning the GIMP example, one has to take into account that in GIMP each layer contains the already-processed data, instead of processing the pixel values on-the-fly… and that’s where things get ore complex.
I had a closer look to your preset, but I still do not fully understand the role of some of the adjustments, particularly the large blurs in grain extract/grain merge mode… I have the feeling that there is some mistake in the way the layers are used. Did you take inspiration from some web tutorial?
Concerning the performances, the main problem is that your preset is chaining five large-radius blurs (approx. 200px each) plus a 7-levels wavelet smoothing. Unfortunately, this is quite overkill for the non-destructive processing engine of PhF, and I have no (simple) ideas for the moment on how to improve the code…
Nevertheless, I’m quite convinced that we could find a more optimized way to achieve the same result… if you like, I’m ready to help you out on that, all I need is a short description of the goal and expected result of each of the adjustments.
While trying to improve the UI, I am also integrating RawTherapee’s RAW decoding into PhF, so that it can be used in parallel with the current one from Darktable.
The first practical result of this integration is that now PhF is able to open and process floating-point DNGs from HDRMerge. This new functionality will be probably committed to GitHub after the Christmas vacations, as I still need to add some code for handling RT’s white balance coefficients (or better color temperatures).
but I still do not fully understand the role of some of the adjustments,
Neither do I, but I respect them the same :P
Did you take inspiration from some web tutorial?
Well, I'm a crushing machine, so I take a little bit of this and a little bit of that... that's why my projects resemble [graveyards](https://youtu.be/KeSAFGWzft8)
And as if that was not enough, I try my best to infect them all with same virus, poor photoflow had to "suffer" kidney transplants from my experiments with the gimpo and gmico bros.
Concerning the performances, the main problem is that your preset is chaining five large-radius blurs (approx. 200px each) plus a 7-levels wavelet smoothing.
C'won that's just the couvert :turkey:
and I have no (simple) ideas for the moment on how to improve the code...
Nevertheless, I'm quite convinced that we could find a more optimized way to achieve the same result... if you like, I'm ready to help you out on that, all I need is a short description of the goal and expected result of each of the adjustments.
Look brother, don't waste your time with me, at least with this preset (too green), honestly; the fact that I cannot read or write code doesnt mean I'm not gonna figure out how to get around limitations and still do things. I do heartfully appretiate the offer though =)
Also and in full disclosure mode - it’s so nice this place at the candlelight, don’t you think? - I know for a fact that it will take way longer to explain myself, which means I would have to analyze my own processing (which painfully I seldom do, no filter, intuition to the power!!) and then translate the scanned data into something “neutral” and understandable by you… a good example is the feather to the inside in github, ha ha ha that was funny; BTW I was surpissed to see that recent LR update started using radial filters feathering to the inside, just a footnote.
Anyways the clone and buffer layers and using them (with curves) as a luma mask already helped… those will kept me entertain for a while. Thank you. I wonder how many secret compartments has PF?
Is the “inside feathering” available for arbitrary shapes, or just for circular/elliptical shapes? In the latter case, something equivalent will come in future PhF versions…
Is the “inside feathering” available for arbitrary shapes, or just for circular/elliptical shapes?
LR only has gradients and circular shapes (which can be inverted and pushed to eliptical). Only circular can be feathered, since version 5 or so either LR and ACR allow for the brush to add or substract from gradients and circular shapes. That’s all, no arbitrary lapse of reason
In the latter case, something equivalent will come in future PhF versions…
@Carmelo_DrRaw - I just wanted to say thanks again, for all your efforts and responsiveness. From my point of view, PhF has an impressive feature set and it looks like the upcoming iterations will cover most of what I need. The main things that I miss are speed optimizations (e.g. for NR), stability (there are too many crashes on my Win 10 machine) and some refinements to existing filters (NR and sharpening in particular; and I think that RT can be a good source for how to improve these).
You could probably help me out with this… I have just uploaded a new PhF Windows installer that includes the same stand-alone gdb.exe that is shipped with RT debug builds (see thread linked below). Just grab the Windows installer tagged 20161221.
The gdb.exe executable is in the bin/directory from the root of the PhF install folder, together with the photoflow.exe executable.
Could you try running photoflow though GDB, and send me the full backtrace whenever you get some crash? That would help a lot…
To get the backtrace of all threads, please run this command at the GDB prompt after the crash:
thread apply all backtrace
I have not tested the procedure under Win10 myself, so I do not guarantee 100% that it will work, but I think it is worth trying…
Still much to learn but that doesn’t mean we can’t share the process {skippy leave that dead politician alone!!}. So here is a new, different, photoflow presset:
Buff dude ------ buffer layer connected to clones, don’t need touchy
satu w HSL ---- basic adj layer in color transfer mode. If you wish to change how saturation behaves, I’ll suggest to turn off all layers above, change satu’s opaticity to 100%, turn momentarily Luma and Saturation (from HSL) curves off and then mess around with it. When you’re happy enable the L and S curves again; you can also affect specific hues with the remaining H curve.
Worse TM ---- the tone mapping/large-radious contrast effect. You can change the gaussian layer radious but in my tests, everything below 200s shows halos. Also you can push things by changing the transfer to merge instead of soflight and reduce opacity.
curves // ------ self explanatory, luminosoty mode. This and the above layer both use layer clones calling its buffer dude friend, hence the “//” reminder.
film EMU // — Gmic’s film emulation. By default is set to Fuji Astia; change it to your hearts desire or shut the motherfosset off =)
what, what, the kitchen’s on fire!!! have to go, go go go photoflow gogogo!!!
Happy halloween to everybody, hope you don’t get very sad about santa, we had to… kidnap him, he was getting too fat and reactoionary, he’'ll be back in good shape and black as a panther … or a penguin
Back trying PF … using this build under Windows 10.
When I open a file for which there is some accent in the name (or even in the path) PF crashes.
examples: 20161106_Jalapão\20161117_Jalapão_054.nef or 20150919_Chartres_en_lumière\20150919_Chartres_001.nef
I’ve not this issue when the characters are pure English.
Is there a link where I can find how to do this ?
When I type photoflow.exe on (gdb) prompt (stupid guess ?), GDB crashes.
When I run GDB, then PF in parallel, the command “thread apply all backtrace” is silent.
I tried to use gdb with 20161221 and I experienced a crash but it looks like the bt is not captured. This is my console, can you tell me what I’m doing wrong?
By the way, the number of thread creations and terminations looks very high. There are about 1200 cases of creations and 1200 terminations when I’m opening my PFI file, which includes a very simple workflow - just a layer for reading the RAW file and a layer for curves that includes 3 mask layers. At the risk of saying something that you already know, in general parallelism is good but (a) thread creation and termination are expensive operations so better use a thread pool to keep them at the minimum; (b) context-switching is also not cheap, so it’s better to avoid too intense switches.
I have realised that in the earlier Windows packages the debugging symbols were stripped from the executable, ad that’s probably the reason why you did not get any backtrace… the latest package (tagged 20170111) should have debugging symbols as expected.
The relevant message from gdb is the following:
Reading symbols from photoflow.exe...(no debugging symbols found)...done.
Concerning the threads creation, this is indeed strange… I’m looking into that at the moment.
New development packages for photoflow are available from the continuous build page, they are marked 20170202 (for Linux&OSX) or 20170203 (for Windows).
They incorporate all the bug fixes that have been discussed here.
A quick update concerning the work which is going on in the development branch, particularly with respect to the GIMP plug-in, and in preparation for the next official release:
As a follow-up concerning the new GIMP plug-in interface, here is a short explanation on how to run GIMP and the PhF plug-in under Linux directly from the AppImage packages:
Keep on with your good work!
… or a penguin 