LCH ttools are in my TODO list since a while, and I can put priority on that if there is a request… I’ll keep you updated.
1 Like
Could you explain a bit about “roughly S-shape in perceptual scale”? My impression was that these curves approximate “piecewise logarithmic” curves, using the terminology from this followup article:
but maybe the revised version of the filmic tonemapping works completely differently from the original version?
The PhotoFlow filmic tonemapping does require a lot of fiddling to get nice results, with each parameter interacting with the other parameters, sometimes even producing a solid white or solid black result (some of the parameters shouldn’t be pushed all the way to the left).
Also, there doesn’t seem to be a set of parameters that produces “no change”, something the “Piecewise Power Curves” article talks about.
Would you be willing to add the modified filmic curve from the second article to PhotoFlow, not as a replacement but as a new module, maybe “filmic1” and “filmic2”?
Anyway, filmic might just be “curves”, but there is no way using GIMP curves that I’d be able to produce the same results as the filmic tonemapping algorithm.
I’m still trying to work out which filmic parameters correspond to the various portions of a characteristic curve. Is “linear angle” related to “gamma”? which I think in this context refers roughly to the slope of the more or less the linear portion of the characteristic curve?
Anyone have an explanation for “toe number” and “linear white point”?
The second filmic worlds article has a link to a nice explanation of characteristic curves: (WFsites) - Page not published
And for anyone who really likes diagrams and equations:
I have similar questions about filmic.
Yes, I was referring to that above. E.g., setting preserve colors to 1 in ACES linear causes problems. Something might be amiss.
Hi afre,
I wasn’t sure - and I’m still not sure 
- what the post you referred to was about. But the ACES color space wasn’t designed for editing, but rather for storage: Redirecting to Google Groups
ACES isn’t just one color space but rather an entire processing and storage protocol that includes several RGB color spaces. If there is a reason why you want to work using one of the ACES color spaces, I’d recommend ACEScg.
For many RGB editing operations (those based on add and subtract), results are the same in all RGB working spaces.
For many other RGB editing operations (those based on multiply and divide by any color other than gray, and also those that modify individual channel information such as mono-mixer/channel mixer and using Levels/Curves to modify individual channels), results very much depend on the RGB primaries. I explained this - with illustrations and in excrutiating detail - in several articles on my website on why unbounded sRGB is unsuitable as a universal RGB working space. But the principles apply to all RGB working spaces - unbounded or otherwise - simply because many editing operations produce different results in different RGB working spaces, depending on the primaries.
Changing topics, I’m fairly certain that “preserve colors” set to 1 in the filmic tonemapping is the same as blending the results using Luminance blend mode - results match doing this in GIMP starting with filmic tonemapping done in PhotoFlow on a “luminance-based” black and white rendition.
Luminance blend mode can produce very vivid colors in any RGB working space, especially in the brighter colors, if these brighter colors were already fairly colorful in the original image and the tonality that’s being blended is considerably brighter than the original tonality.
Getting back to ACES, many people have thought “Oh, I’ll use ACES because it holds all the visible colors”. But when dealing with camera raw files, for many cameras - and depending on how the input profile was made - bright yellow and dark violet-blue colors are going to be interpreted as outside the visible colors, that is, as imaginary colors. The solution to keeping all the colors isn’t using a larger RGB working space but rather is using whatever procedure you can find or devise that brings out of gamut colors back into gamut.
A serious problem with using any large (as in considerably larger than your monitor profile’s color gamut) RGB working space is that you can easily produce colors your monitor can’t display. PhotoFlow soft proofing can be used to soft proof to your monitor profile, using the gamut check, which is a nice way to see just how many colors are outside your monitor profile’s color gamut.
I was probably not very accurate with my statement… the resulting curve is “kind of” S-shaped, but the key point is that it handles values > 1 by bringing them back analytically into the [0…1] range.
Thanks for pointing to the follow-up article, I’m coding the new formulas right now.
Wow, awesome! thanks!
This is what led to what I said.
Which does not happen when I do not clip the negative values in ACES, ACEScg or Rec.2020. The resultant max values are extremely large and, when I scale or clip everything to [0…1], I get a very flat grey image.
In my case, not solid black or white but very flat. (This ties into the discussion of what filmic and its parameters actually do, which led me to think about the things that @Elle has just asked about.) I guess the takeaway is that filmic and possibly other modules in PF are simply not equipped to handle images with negative values.
As for the negative values that result from filmic, they only appear when I use ACES, no matter which values I clip or do not clip. Based on what @Carmelo_DrRaw and @Elle have said, these colors are out-of-gamut, but I didn’t expect them to be this extreme.
Anyway, I look forward to filmic2.
Oh, I think I know what you mean. Not too long ago I filed an official GIMP bug report complaining about a layer mask turning solid gray after doing an autostretch operation, and someone kindly pointed out that the mask turned gray because of the negative channel values. Oops! Anyway, @Carmelo_DrRaw 's advice to clip the negative channel values during raw processing seems like excellent advice.
The images I’ve been using for exploring the filmic options didn’t have any negative channel values, so the filmic “solid black or white” results from pushing a couple of the parameters all the way to the left is from something other than negative channel values.
This has to be considered a bug, and needs to be corrected. The easiest way of dealing with negative values is to introduce functional relations of the type
f(-x) = -f(x)
Could you share an example of badly behaving filmic adjustment?
Thanks!
@Elle @afre I have committed a first test implementation of the new filmic tome mapping curve suggested by Elle.
For the moment the new code is only available from sources or the Linux AppImage, but I will prepare updated OSX and Windows packages as soon as I manage…
Looking forward for your feedback!!!
Thanks! the new code built without any problems, and tomorrow I plan to spend some time testing and comparing.
One thing in PhotoFlow, not directly (or rather not only) related to filmic tone-mapping, that I wanted to ask about is how does one get the PhotoFlow sample points to read out in LAB? And can they be set to read out in LCH?
For example, for the image at the top of this page: Pictures in progress - while using the filmic tone-mapping I wanted to place the sky on the right at around L=50, the sunlit face of the building at around L=85, and the deep shadows under the small white car in the middle at around L=4. I ended up typing the PhotoFlow sample point RGB values into GIMP to get the equivalent L values, which was a bit cumbersome.
In RGB color spaces, the meaning of RGB values changes from one color space to the next. In strictly black and white images, the only relevant factor is the ICC profile TRC, and for the filmic operators it’s best to use a linear gamma TRC. But even so, “L=50” as middle gray is easier to understand than R=B=B=0.18. And “L=95” as the maximum printable brightness for a good photographic paper on a high quality printer is much easier to remember than the equivalent RGB values. And so on.
When you turn to color instead of strictly black and white, the ICC profile TRC still matters, and also the RGB primaries that define the color space matter. So for example AdobeRGB greenest green is considerably more green than sRGB greenest green. In LAB space any given green always has the same LAB values. and of course the same is true for LCH values.
So you can just remember, for example, that an LCH Hue of 119 is a nice spring green, instead of having to remember every single RGB combination, for every single RGB color space that you might want to edit in, that converts to a LAB/LCH color with Hue=119.
@Carmelo_DrRaw - Is there a way to set the filmic1 or filmic2 paramters to guarantee the upper and lower values for brightest bright and darkest dark? It seems like in filmic1 “lin. white point” and “toe density” ought to be related to setting these upper and lower limits, but so far I’m not really sure what modifying these parameters actually accomplishes.
Oh, speaking of “new tools” I forgot about the RawTherapee CIECAM02 code. Well, it’s not new in RT, but it’s new to me, and the recent updates make that code absolutely awesome.
From curiosity, what kinds of editing are you doing with LCH? It’s nice to hear that someone else finds LCH absolutely indispensable for editing.
I agree with you that having LCH in PhotoFlow would be really nice. I’d still continue using GIMP because of other tools, and because layer masks in GIMP can be painted on, plus I’m enjoying using GIMP for painting/drawing. I think PhotoFlow probably would be difficult to use for painting.
@Elle re LAB. Good point about its utility in comparing colors. I actually do that myself already. As for the readouts, as far as I know, the only way that it can be done thus far is change the working space to LAB. However, that may change the preview image’s appearance and you may have to wait for the conversion. I have made a feature request earlier concerning the samplers:
@afre - thanks! for linking to the other post.
From curiosity, what kinds of editing are you doing with LCH? It’s nice to hear that someone else finds LCH absolutely indispensable for editing.
For me, I sometimes use LCH because when I edit a image, I’m looking at what I’m seeing. My workflow tends to involve mainly only manipulating colors and shadings with a bit of repairing as I don’t need to use things like liquid rescale, so I tend to use Krita instanced layers, and filter layers/mask with some clone brush (healing enabled or without healing), vectors, g’mic inpaint, and so on. If what I’m seeing is not easily replicable in terms of colors within any of Krita color models and blending model or filter mask/layers, I simply swap to GIMP for a while, and do a bit of blending there, and copy and paste result to Krita and continue doing my nondestructive editing in Krita. I really do like having the ability to go back and adjust the parameters of my edits, and continue going forward without having to start all over again. I do wish I can have latest GIMP .xcf file layer within Krita so that I can combine the two programs to their advantages and disadvantages (GIMP incredible series of destructive tools+Krita nondestructive editing that is actually better than Affinity Photo and Photoshop when only bases are covered and ignoring the lack of filters)
That’s why I use GIMP LCH tool. To have a tool that better reflects what I"m seeing in my head whenever I really need it. I actually have a uncanny ability to replicate functions in my head, and see the results.
Refer to post #19. I neglected to mention that I also did this:
- Do it on _MG_0419.
- Export it as a TIF.
- Examine its values using G’MIC (or ImageMagick).
Actually, on closer inspection, at least for this photo, the unusually high pixel values appear to be in the shadows, which means the min values were so low that they may have wrapped around. To see that:
- Open TIF from step #2 and enable highlights clipping warning.
PS Did you read the part about load time? 29-38s of updating is pretty long.
Ah, I think I know what you mean. I don’t have a particularly good color memory, but I remember using Krita once and wanting to paint “this shade of sky blue from this particular photograph, but darker and more saturated”, and none of the HS"X" color space sliders in Krita were working to get the color I wanted. I ended up typing the color’s RGB values into the ArgyllCMS xicclu utility, converting to JCH, modifying the J and C, and converting back to RGB - a very slow way to pick colors!
Yes! I am keeping your edit as some one of my benchmark, to see if I am doing some concrete progresses on the code optimizations… however, that will be a long work, unfortunately.
1 Like
@Carmelo_DrRaw I spent some time reading about filmic2 (article linked by @Elle) but I haven’t gotten a chance to try it since I am waiting for the Windows release of PF. Remarks:
-
The explanation in the article was easy to follow, though I found it hard to visualize the outcome with just the text and numbers.
→ Feature request: would like to have a curve as a visual aid to the slider adjustments.
-
I like the idea of overshooting to improve the appearance of the highlights on the shoulder. It is a solution to a problem that I have had with my own curves.
-
The author prefers applying his technique to separate channels as opposed to luminance to maintain detail, but wouldn’t that result in a shift in color? How about applying it to lightness?
Update re strange ranges that come from the use of filmic. It still happens. There was a raw that had 1+ values even though negative values were clipped (with preserve colors enabled, I think). I wonder if it also has to do with the exporting because I generally export before I re-examine the images. Lately, I sidestep the issue by setting the layer blend mode to luminance and all is well.
Update #2 Switching to blend mode color when using filmic or filmic2 crashes PF most of the time but not always for certain images.