I think you just misunderstood me here. I wasn’t talking about what people actually know or don’t know, but about the inhibition to participate that is based in the fear of embarrassing themselves if it turns out that they - among other things - don’t know enough. This is a subjective feeling, which has nothing to do with actual judgment from the outside.
It’s about the fact that people just don’t participate - regardless of what level of knowledge they have.
I agree here.
Why not? How else would I know what kind of problem he has? Why should I guess around? He can talk and answer the questions if he expresses something that requires further information. But that does not mean that I expect him to have a degree in physics to be allowed to talk.
I agree and that is precisely why there is a need for exchange. But exchange is not when you throw something out without wanting to justify it. If you are unskilled, this is the way to learn.
I lost in the second solution. I just use the tone equalizer to bring back the highlights or just add another exposure with masking for the area I want to pull back. There is a lot of space below the scene tab. I wish the look properties could be move there and maybe sliders reduce.
I agree that this is the case. But the assumption that this is based on fear on the participants side…I mean that would need a whole lot of investigation to prove that point. (Maybe regular polling might help to investigate this)
Maybe that’s what is keeping people from proper error reporting, the fear that if they do it wrong, they’ll be dismissed?
Also: credentials or a portfolio don’t help you reducing the guessing on your side.
Sure, but a portfolio would be equally non-helpful, imho. Communication is helpful. Maybe you meant communication-skills? I can fully agree on that.
In the configuration if you use the recommended scene-referred workflow then filmic rgb is turned on automatically for all photos that are imported. In fact, I don’t see a way to use the scene-referred workflow without using filmic rgb, but that is probably just because I do not understand something. It seems like scene-referred workflow and filmic rgb have been inadvertently conflated.
@bakubo: The workflows are different ways to achieve a useful default image. You can either use “display referred” which uses the base curve and legacy module order to achieve this, or you can use “scene referred” which uses exposure, filmic and the new scene-referred module order. If you choose “none” you can get the scene-referred module order but without any default modules (except those that can’t be avoided).
You can also use presets to create your own default behaviour.
Filmic and base curve are the recommended modules in scene- and display-referred workflow to tone map your (likely high dynamic range) raw to your (likely low dynamic range) screen. You can still use base curve in the scene-referred workflow if you like. It’s just later in the module order.
This is key. There is no restriction on which modules to use.
The advantage of scene-referred is that you maintain some semblance of relationship with the original capture and hopefully that relates to the actual scene if you are careful with your photographic and post-processing workflow.
The whole fuss started when people began to realize that the base curve while convenient marred the relationship between the scene and subsequent edits, that it would be easier and better to keep the ratios and have tools develop the image progressively rather than haphazardly. Trouble was that those tools had to be written.
filmic(rgb) like many other new or revamped modules is in that trajectory. In dt, if you hover on a module, a tool tip will pop up and tell you if it is suitable for scene-referred development. Just be careful to use it as such if both scene and display are shown in the tool tip. Means that the tool may have features that don’t respect the scene.
I’ve exported the neutral image from darktable and imported into vapoursynth.
Probably i’m doing something different from the darktable’s filmic implementation because i’m using the inverse log formula after the contrast enhancement (while in darktable there is only a gamma adjustment ?).
This enable us to work with >1 output
do you apply channel-wise, or do you convert to ICtCp and only apply to I (or to JzAzBz and only to Jz)? The only image where the sky shifts to cyan is where you tone mapped to 200nits, so technically you’re intentionally blowing out channels/range IF your step7(?) includes values that get clipped when going from linear to sRGBgamma.
It isn’t possible to use the hermite spline in linear space but the st.2084 transfer curve is pratically a logarithmic space so we could use the formula used in darktable
y={log2(x/0.18)-blackEV \over whiteEV - blackEV}
find the knee point fixed at middle gray 0.18 for simplicity
Right! I promised more maths, here is more maths: the_maths.pdf (250.6 KB)
This is 8 pages of rather theoretical stuff but just in case anyone wanted to see how the curves are derived. This is not written to be very easy to process because this actually took me about as much time as solving the equations and making the Desmos mock-up. This also means there might be typos in it. The equations should be correct though, because they’re the same ones as used in Desmos. @anon41087856: I’m sending you the TeX file, too (can’t upload that here).
Not covered: What’s the most elegant way of constraining the variables which need to be constrained?
This is relevant because the linear segment needs to be prevented from extending to 100% (99.999… is fine, but not 100) or to 0 (same thing), and contrast also has a lower limit. I have ideas for that, too, but that’s for another post, coming soon…
Next up: which parameters to expose, and how …
