Do you have a display that allows you to feed unadorned analog directly to the display plane? Ever since my dialogues with troy_s, I’ve yearned to see such…
Aren’t VGA ports analog ?
Is good to know I’m wrong, because that way I can learn something and not being wrong anymore 
Thanks for the clarification.
That is, getting results without artifacts (odd colors, details where there wasn’t any detail, and so on). I agree with you.
I trust you!
And now, as I don’t have enough knowledge about all these details, I’m going to withdraw discreetly into the background to read and learn 
1 Like
Well, don’t withdraw. That’s fine. You are not the only one, and I truly want to understand where all these wrong assumptions came from.
People have been stuck in this faulty display-referred workflow for 2 decades, to a point that now, they don’t see another way around. Why is that so ? Grand-dads have done a tremendous job with only scalpels, lenses, masks and ink in darkrooms for the past 160 years. But for some reason, geeks have taken over in the past 30 years, didn’t care about staying consistent with that stuff, and awefully mixed view/model/control in softwares to a point it became a de-facto standard. Well, shoot film, you will understand.
When you record a picture, you record a light emission. When you display a picture, you display a light emission. When you open an RGB file, you open something encoding a light emission. When you push pixels in a photo editor, just treat your pixels as encoded light emissions. Thus unroll the physics, and stick to it. Yes, your eyes don’t care about that way. But we have been mixing colour in paintings for damn centuries before even beginning to understand light and how we actually see colours.
All in all, we don’t care about colour. We care about light. Colour is what happen when light enters our perceptual system.
2 Likes
That’s not really the case, but you can find regions where the light output power is proportional to the input power, but for higher power, the efficiency typically goes a bit down. There is as well a range where the input power is almost proportional to the input current, but that’s also not the full operation range (dependent on the application). However, this is anyway not relevant as this is not how a typical LCD works (not talking about OLEDs here, these are again another story, but for our larger displays they are not used anyway for good reasons). In a display, LED light output power is only altered for what they call “dynamic contrast”, which we can neglect for image processing I guess. But however the response curve of the display over the input data is, there are clearly defined interfaces that tell how the data is expected at the display’s input. At least I hope so 
.
To me, that has an easy answer after answering another question: who has been the de-facto omnipresent God of digital image editing? Photoshop (and all it’s siblings).
I was a Photoshop and Lightroom user until that CC crap came, and was never happy with the amount of work needed to get a decent image.
As a plain user, I never knew what I was doing wrong, and I just settle thinking that «things work that way». Things like oversaturated colors just after loading an image, some kind of fog covering most of the images, oversharpening, and so on. Well, in the end I knew that there was ways to undo what the smart software was doing…, mostly. I was certainly not happy having to debeautify something that someone thought was a better processing than what an ignorant like me could do.
And then, one day I tried FOSS software, and suddenly my images looked better (to a certain extent 
). I read, and read more, and finally found that the main difference was that Photoshop (and siblings) where not working in a linear way (thus, my foggy images). Yes. Lightroom was the reason I had to use several tools to remove that fog. With DT or RT? Not anymore.
So I learned the hard way that working linearly is absolutely vital for my images.
Did I mixed concepts and named things with the wrong words? Yes. But it’s difficult to find a perfectly good explanation out there in Internet. Thus: confusion and wrong assumptions.
Do I know something about display referred or scene referred workflows? Not really. But I DO KNOW how a bad programming creates havoc in my images. And in the end that’s what I’m worried about.
I shot B&W film, and developed it myself, and processed my own prints. I know (and still love) what it was like. And then there were several tools I could use to get my images: chemicals, temperatures, processing times, films, papers…
When I developed a film roll, I could choose any chemical I wish, process the film or push process it, change the temperatures, anything… But in the end I knew I would get a roll of translucent film with black dots creating patterns in it. Exactly what the next tool needed (the enlarger). Not a yellow, opaque or speckled film, but a translucent one.
If I ask something to a raw developer today is exactly that: their tools have to do what they have to, but they all have to end up with the same result, that is, image data «encoded» linearly. Why? Because if not, I go back to the Photoshop annoyances.
Probably I have entered a field I know little about (programming), and most probably I’ve seemed silly, but I knew exactly what I was searching for. And I bet that most plain users know it too, although they have no idea how to technically explain it.
And as a final comment, I don’t know about others but I do care about color, and I’ve read that color is really really important for human beings survival (it has been that way forever): «color» is a reaction to certain wavelengths, and what is different between different people is how they call it or how they decipher that stimulus. One may call a certain stimulus orange, or reddish, but most probably will never call it blue, because that is another wavelength, thus another different stimulus.
What I see is that we (users) shouldn’t care about how a raw developer works with color internally. But we do care about the results, that is colors.
5 Likes
LED output is roughly proportional to current, not voltage. LEDs aren’t linear, but the control electronics of any properly calibrated display (and even displays normally not considered “calibrated” to photographic standards have at least this amount of calibration done).
Or, more commonly, the LEDs are driven at a fixed current (often with “dot correction” calibration offsets), with their duty cycle PWMed since this doesn’t lead to such nonlinearities.
PWM dimming is basically a requirement for most white LEDs since the nonlinearities of the phosphors will cause spectral content to shift with current. (Underdriven LEDs are often greenish, overdriven start turning bluish)
This only applies to OLED displays and the rather exotic (and usually very large and very expensive) MicroLED theater arrays. What most people call “LED” displays are actually LED-backlit LCDs. The actual backlight control scheme depends on low-level details of the display architecture, most notably almost any high dynamic range LED+LCD display uses local dimming.
In anything but a legacy CRT, going right into an ADC bank.
Computer stuff is pretty simple if explained well. When you consider it’s essence, a digital image is a pretty simple construct, a width x height array of numbers, each being the measurement of the light energy inflicted upon a corresponding position in the sensor. Those measurements are encoded as integer numbers, using, instead of digits 1-10, digits 0-1, or binary numbers (probably the hardest computer thing to wrap your head around for the essentials). And so on, in a “baklava-like” layering of fairly simple concepts.
To the intent of the thread, it’s those original measurements that we disturb with each and every one of our subsequent operations. Specifically, we disturb their original (linear) relationship that conveys the originally illuminated scene, and that disturbance introduces things that don’t look like the original scene (artifacts). While “linear” is typically discussed as retaining that original energy relationship of the measurements as long as possible, I also believe it should include minimizing the number operations needed to produce a pleasing rendition. We tend to “whipsaw” the image with our application of multiple non-linear tone curves, each of which further disturbs particularly the relationship of the R, G, and B channels of data.
For instance, I’ve played a bit with having the color conversion from camera space to rendition space include the transform that corrects white balance. Usually, those two things are done separately. In my limited experiments, I have definitely observed retention of more color when combining the two. But, it’s a pain to make color profiles for each session, so I continue to bork my images with separate white balance multiplication…
It’s not about ‘ending up’ linear, it’s about keeping it linear as long as possible. For a variety of reasons, we have to apply one or more non-linear curves to images to “make-nice” for final viewing, it’s a matter of putting them in the right place in the pipe. This consideration applies to any and all raw processing softwares. Some are better at telling you that sequence than others; some specifically don’t because they’re trying to protect you from the weeds, so to speak… Oh, and some let you determine the ordering yourself, at your peril… 
2 Likes
Thanks for your explanation
But I have to kindly say otherwise about linearity (as I see it): it’s true that an image has to be kept linear as long as possible, but to me that means exactly from end to end.
Let me explain, because maybe we’re telling the same and I don’t see it: the image enters the raw processor in linear encoding, then enters the first tool (I think it’s the demosaic tool, or close to it), and leaves it in linear encoding. The image goes from one tool to another in linear encoding, but we keep watching how it changes in an icc profile encoded way (be it linear or «gamma» encoded). We never see the image as the software does, because there’s always an icc profile that translates it to show it on our displays.
But it happens that the image enters a tool that «gamma» encodes it, or applies a power function to it, or however it is correctly said. The tool works with the image non-linearly, and that’s fine, because that’s the way it should do it. But then it converts back the image in a linear fashion. And the image keeps going to the next tools linearly encoded, up to the end. Mostly. Because to us, the real end is the export tool, where the image is definitely gamma encoded (usually with sRGB encoding).
I insist on this because if one tool applies a power function of 2.0, and pass the resulting image to the next tool, that needs to apply another power function of, say 3.5, what would be the result (a power function of 3.5 over another of 2.0)? And if there are 4 consecutive tools like that?
I understand that the way I expect them to work is how raw processors work indeed (at least FOSS ones), but up to now I haven’t read anywhere that they clearly work that way.
P.S.: I’m not trying to be stubborn, just trying to not be wrong anymore
I understand what you are saying, that we ought to leave no trace, as an outdoors person would put it. It is true that different tools expect different input. It is up to the dev (or user) to adapt the tool to the workflow.
This has been a real problem for GIMP, after the devs decided to allow for more modes of editing. Since then, it has taken a long and winding transitional road, confusing much of its user base.
1 Like
No worries, it’s really not easy to be right…
That’s one of the reasons I wrote my own raw processor. I wanted to open a raw image as-is, then apply the tools needed to get the needed rendition in the order I wanted. This was as much about learning just what you’re after as well as have explicit control over each operation.
I really don’t like the idea of tools that do some other conversion beside the thing that it semantically is doing for me. One of the most instructive things I read in my early days of doing this was the raw processing tutorial in the GMIC wiki:
The author uses dcraw to get the basic RGB array, then pipes it into GMIC for the other things. Very insightful, and it’s this by-hand constructed “toolchain” idea that led me to write rawproc.
I’m going to construct such a video tutorial using rawproc, sometime soon. Need to get my office in order, buy a couple of things to facilitate capturing video and narrative audio. I may fall back to a text/screenshot sort of thing, but not ready to do that yet…
2 Likes
The correct link is Developing raw images with G’MIC.
@heckflosse So much power when logged in.
3 Likes
Thanks; another example of software doing things for you, with unintended consequences… 
Just dropping stuff that was sent to me yesterday by an anon user now banned from this forum:
Right. It’s been a while since I played with those. Bad memories…
1 Like
Please, again, a computer display as we use it to view pictures does not modulate LED light emission: Liquid-crystal display - Wikipedia. The constant emission of the LEDs is modulated by a layer stack of liquid crystal, electrodes and polarization filters.
Edit: Sorry, discourse got the quotation wrong, but don’t know how to fix from my phone.
1 Like
Unburying that topic with some examples:
Left is blurred in scene-linear RGB then converted to sRGB for display. Right is blurred in sRGB prepared for display.
Lens blur applied in scene-linear RGB then converted to sRGB:
Lens blur applied in sRGB prepared for display:
original image by Hanny Naibaho:
Another self-explanatory example of accurate lens blur can be found on Chris Bejon’s website.
So I hope this will finally close that non-issue. Scene-linear is not the best, but the only way to get a proper blur. Which is something you need all the time in image processing to blend and soften masks, and also to sharpen pictures. That applies to compositing and background-switching too.
If you want to push it, painting with actual pigments also happens in a scene-referred space, which doesn’t prevent you from mixing colours, even though these pigments don’t give a flying sh*** to your perception.
All in all, the challenge is only to make software GUIs speak scene-referred, which is not entirely possible yet because of bad design mixing view/model/controller in twisted ways. But clean your pipe, undo hard-coded assumptions on grey or white value, and done !
5 Likes
True
Partially untrue , for convolution sharpen
All of this is well known and extensively tested
While blurring might be better at an ultra-low gamma, sharpening and addition of noise are worse, so having filter operations take place at a low gamma generally is a bad idea.
Dan margulis 2002
https://www.ledet.com/margulis/ACT_postings/ColorCorrection/ACT-linear-gamma.htm
Maybe only for deconvolution sharpen (deblur, capture sharpening) is better linear gamma
Deconvolution is only a fancy iterative unsharp-masking to remove lens blur. Lenses work on photons, therefore in scene-referred space. There is absolutely no reason to perform deconvolution in non-linear spaces, unless you want to sharpen noise.
The post you are quoting comes from 2002, when I believe image processing was done in 8 bits integers, and in this context maybe the benefit of avoiding posterization while deconvolving integers superseded the artifacts it creates.
But in 2020, any serious soft works with 32 floats and deconvolving needs scene-linear RGB because it needs to blur first to deblur then.
That Timo guy they made fun of in 2002 on that mailing list was actually right, and the rest of them jerks are assholes. Most of that thread is pure BS that is proven wrong everyday by the 3D compositing world.
PSF are physically-defined objects. There are no partial maybe, no more than there are gamma-corrected lenses.