What I propose is fully independant channels, working early in the pipe, like simple selective exposure adjustments, in a way that preserve both colors and local contrast.īe extra careful with "simple". It can be also damaging for color preservation and local contrast preservation. Zone system works too late in the pipe, and in a way that need to take from one zone what you give to another. I'm just trying to explain that what seems simple from an user-perspective is not necessarily future-proof and trying to replicate front-end features without undestanding the underlying assumptions they make can blow up in your face. Different points of view are to be expected between devs and users. Or you get a half-baked shadows-highlights module, that is simple to use (maybe) and messes up you colors at the same time.ĭon't apologize, it's ok. Sorry, but in this case, reliability and simplicity cannot be achieved at the same time. So I split the dynamic range in 8 evenly-spaced channels, every 2 EV, from 0 (white) to - 16 (black), I give you a cursor to manage each channel, and you will be able to adapt to every possible exposure scenario without having stupid devs making stupid choices for you, assuming you are more stupid than them and too lazy to read a manual. The only thing I know is cameras have a top dynamic range bounded at 16 EV, because they use up to 16 bits integer encoding. Is that reliable, systematic and reproductible ? Nope. And the thing is "highlights" (as in LR or C1) can actually mean "whites", "highlights" or "midtones" depending on the picture base exposure. basic options, is just about having physically-meaningful options. So, I understand that users love having 2 cursors doing magic for them without the need to understand what's going on, but how do you expect me to know, at the time I code, what is the luminance range of highlights for today's, yesterday's and tomorrow's cameras, at the current ISO ? Because at 3200 ISO, most cameras have barely 8 EV of dynamic range remaining. And that depends on your scene, camera, ISO setting, etc. Meaning your "physical" highlights can actually range from 12.5 % to 50 %, up to 100 %. Meaning the actual mid-grey can be as low as 4 % luminance. Now, with 14-EV cameras, 100 % luminance can be direct sun-light, but since everything above is still clipped, you exposed to the right and recover shadows later in software. All in all, you exposed for mid-tones, got your grey at roughly 18 %, and there was not much variability in pictures, so you could just decide that highlights were above 50 % luminance, and shadows below 0.8 %, and that was about it. So, everything below 0.4 % luminance was assumed black. So, middle-grey was at 18 %, and, with older cameras and color-film, black was at -8 EV from diffuse white. The whole ICC color-management chain was built assuming 100 % luminance was diffuse white, and everything above was clipped. Now, having more than 14 EV of dynamic range at 100 ISO is standard, and it's HDR already, since JPEG and most displays have only 8 EV available. The point is not to achieve higher dynamic range than the camera offers (that's not possible), but take full advantage of what the camera has in its guts. When a photographer wants to achieve a higher dynamic range than his camera allows, the only way is to shoot raw and work on it in an image processing software. More controls, but the same use principles apply, and nobody will decide for you how large the highlights range is. You will have whites, highlights, mid-tones, shadows, deep-shadows, blacks and deep blacks instead. Having a tone equalizer is not much more complicated than a simple shadow/highlights. In these setups, "highlights" can have very different meanings. The ICC workflow is not well-suited for HDR work, and we have to think of future-proof workflows that can use ICC but don't rely on it. So, that sums up to a very simple design dilemma: do we want a fixed tool, simple but limited in use because of all the underlying assumptions it makes without telling you, or an all-purpose tool, adaptable but with more parameters ? If you work in HDR scenes, you are screwed, because that doesn't fall into the "correct" use-case they designed for you, on the assumption you will work on camera raws in an ICC workflow. Problem: these meanings assume you work in clipped display-referred RGB space, in an ICC workflow. They have decided for you what "shadows" and "highlights" mean in terms of luminance values. Lightroom and Capture One have users trapped in their engineering decisions. I will never understand why users go on the raw path to take control on the pictures, while just wanting simple basic modules that just work. At the end of the day most users use several basic modules and we need to make sure they are the best possible.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |