@ngoductri this room deals mostly with cycles, color management, and related themes. For blender internal try posting on the chatroom called "the renderfarm "
@GiantCowFilms If you are using a different coloured set of lights, either A) all the colours are correct or B) all the colours are wrong. You are using your eyes, which is wrong. Use your brain.
@GiantCowFilms Only one of those answers can possibly be correct.
@GiantCowFilms Not really. You didn't understand much prior to the start. You simply need to treat this like building a brick wall, brick by brick. You now know more about camera formats, display linear, scene linear, and a little more about ratios.
@troy_s @troy_s I know that the reason for color shift between images in different color spaces is caused by different responses to brightness values for each channel.
@troy_s No, all this misinformation comes from guessing.
@GiantCowFilms There is always a transform from the scene referred domain to the display referred domain. It is a transfer characteristic or transfer curve. How values are mapped.
@GiantCowFilms You should be certain. Make sure that you are using the correct lights for your experiments. In this case, given where you are at, those should be 709 lights (aka sRGB)
@someonewithpc So when someone says "sRGB", despite being a well documented specification, they are likely misusing the term.
@someonewithpc sRGB has a very specific two part transfer characteristic (EOTF) and a very specific set of three colours for each of the red, green, and blue lights.
@someonewithpc Which are 709 coloured lights (ITU.BT.709)
@GiantCowFilms 709 and sRGB's transfer characteristic will only operate on normalized ranges, aka 0..1. Your scene referred series of values is infinitely small to infinitely large, and specifically a small lower value (of your choosing for a "black") and an arbitrary upper value (for display referred "white")
@GiantCowFilms Ok so you tell me how to do it. If you have the answers, do not ask.
@someonewithpc The best way to always think about pixels / light / colour is that there are two halves: A) the linear or nonlinear way that the lights are encoded for intensity and B) the colours of the three lights.
let say, to keep things simple, they produce equal amounts of light when their sliders are at equal positions, and the slider percentages adjust the output light linearly
We want to shine a hue that is 5% of flashlight one, 20% of flashlight two and 80% of flashlight 3's output
@GiantCowFilms I'm probably miss understanding this, but you don't have less in the HDR, so you just need to convert that (scene referred) with the appropriate curve, in a way that doesn't clip anything (in a perceptible way)
@someonewithpc Think about what an RGB value means; it means one thing and one thing only. It is a means of communicating the intensity of a light - red, green, or blue.
@someonewithpc The key revelation here is: A) Without further information you don't know what intensity scale that encoded value refers to and B) Without further information you have no clue what the colours of the lights are in any given encoded value triplet.
@GiantCowFilms It isn't complex. Assuming your base unit is 0.9, and you want double the emission strength, the second unit is 1.8. The transfer curve if you want to keep that dynamic range, would need to map 1.8 to 1.0 for the display referred transform.
@someonewithpc No. When most people say "sRGB" around Blender, they are typically referring to the sRGB transfer curve; the function that maps 0.0 to 1.0 range to display.
From the display linear domain to the display referred nonlinear domain.
The transform of intensity that maps scene referred values to thedisplay referred domain is unique and depends on the context of the scene and or pipeline.
@someonewithpc Just remember that an encoded value means some intensity of some colour of light. We don't know the colour nor the intensity mapping. You always need additional information, with which, you can properly interpret and transform the lights from one space to another.
@someonewithpc cinematiccolor.com has a good PDF. Probably a little higher level than where you are at right now, but a solid document endorsed by the Visual Effects Society
@GiantCowFilms There is no such thing as an average user. So give up on that.
@GiantCowFilms What part of what I have said makes you believe I have said it is not a creative transform?
@GiantCowFilms Make the transform whatever range you want.
@someonewithpc Physical and mathematical in some instances. If you zoom in on your display, you will see three emitting lights per pixel. Those are the lights.
To get images that seem more photorealistic, not only a much wider Dynamic Range is needed, but also having the color information desaturate towards white as it would happen in an overexposed photograph.
This all follows from an answer on this question
The default sRGB output view transform ...
@GiantCowFilms Non performs no transforms. Technically that is a dump of data to your display, which means dumped via sRGB lights at whatever value. It is a meaningless view in terms of what you can infer from it as it depends on whatever device you are viewing it on.
@GiantCowFilms (at risk of complicating the hell out of things, your display also has a hard coded transform at the hardware level baked into it if it is LCD etc. But I will skip that.)
@David It is a Rabbit Hole. Just be comfortable with not knowing and it lessens the duress. Try to latch onto small pieces and understand the small bits as best as you can. They will connect together, so a small bit at a time is a huge win.
Best advice for both is to realize that all of the more seemingly complex elements around the XYZ space and research is all just an absolute colour model and space.
Unlike RGB, which is 100% relative, XYZ is a model (three colour just like RGB) that lets us discuss colour in absolute terms.
So XYZ is a Rosetta Stone of sorts; it lets us actually communicate what colour those reddish, greenish, and blueish primary lights are in an absolute way.
@David I keep saying it is a mantra: to really begin to grasp RGB, understand that there is an intensity encoding (display linear, scene linear, sRGB transfer, 709 transfer, 2020, you name it)
A colour for each of the three encoded values. A reddish (not always) colour, a greenish (not always) colour, and a blueish (not always) colour.
@David XYZ is the "glue" that lets me say to you "sRGB's white point is X 0.3127 y 0.3290" and that means one precise colour and one precise colour only.
To get images that seem more photorealistic, not only a much wider Dynamic Range is needed, but also having the color information desaturate towards white as it would happen in an overexposed photograph.
This all follows from an answer on this question
The default sRGB output view transform ...
