> Isn't it much better to simply make monitors that correctly output the sRGB colorspace instead of being broken and requiring calibration?
Uh? You know nothing about making monitors, right?
Even if monitors were 100% correctly calibrated initially, the color balance of monitors can change with time..
Hughes: Introducing the ColorHug open source colorimeter
Posted Nov 14, 2011 18:08 UTC (Mon) by drag (subscriber, #31333)
[Link]
That's one thing: Monitors can change colors for quite a few reasons. So they will periodic recalibration.
=--=-=-=-=-
Plus there is no such thing as 'correct sRGB colorspace'. Colors change constantly. To think there is one set of 'correct colors' is just mistaken.
Print out a image on a piece of paper. Look at it under a incandescent light, now look at it under a floresent light, take it out in the morning sun and look at it, take it out into the afternoon sun and look at it, take it out in the evening sun and look at it. Look at with a gray back drop, now look at it with a blue back drop, etc etc.
Each time and each condition the paper will have radically different colors. Colors of everything change constantly because the colors are mental construct that are dependent on light striking a surface and shining through it.
As the light changes and our perception changes then so will the colors. Even with a monitor with a set light source behind it will have it's colors affected by the environment.
The point of color calibration is not to 'Find the correct colors' (although obviously you want your monitor to be correctly configured as much as possible). It's to try to color match a process, a work flow. So when you are working with other people and other media then you use your color calibration and color profiles to color match.
Example: if you are working with a video that is going to display output on a movie screen you can get very close to how it will appear on your monitor. Also you can make sure that when working with a dozen different people on different computers with different displays that the color red for you will be the same as them. Same thing with different inputs from different sources. All that stuff needs to be color matched.
Example 2: say you are working with a industrial printer. A industrial printer will use different sets of inks, each with different color capabilities based on how fast you want to print, what material you are printing on, and how much money you want to spend on ink. Each set of ink will have different color profiles and different colors that it's capable of representing. What makes it more difficult is that printing out test prints is prohibitively expensive sometimes. So you only have one shot to get it right. Color matching your monitor with your printer and also having a desktop layout program that will restrict the color gamuts to the correct ones is very important.
For all of this you will to be able to color calibrate all your outputs and inputs. Scanners, printers, cameras, your monitor.. each will have different capabilities and different color profiles.
it's a difficult problem that nobody has solved yet. But things like this 'colorhug' will help mitigate a lot of the issues artists have to deal with in professional environments using Linux.
Hughes: Introducing the ColorHug open source colorimeter
Posted Nov 14, 2011 19:01 UTC (Mon) by slashdot (guest, #22014)
[Link]
> Plus there is no such thing as 'correct sRGB colorspace'
If there is a point perpendicular to the center of the screen and an input-independent linear transformation of the light distribution measured from that point with no other light sources, such that the result of the above process rounded to an integer is the sRGB value provided as input, for any input and any pixel, the monitor works correctly, otherwise it doesn't.
Hughes: Introducing the ColorHug open source colorimeter
Posted Nov 14, 2011 21:30 UTC (Mon) by dgm (subscriber, #49227)
[Link]
He was not talking about your screen working "correctly", but about getting to see in it the same colors you will get from another monitor, or your printer.
Hughes: Introducing the ColorHug open source colorimeter
Posted Nov 14, 2011 22:39 UTC (Mon) by Wol (guest, #4433)
[Link]
How So?
Because YOUR EYES don't perceive colour consistently! So if you want a consistent experience, the monitor needs to change.
Try this experiment. Place a yellow banana on a piece of yellow paper. They're both yellow, aren't they ... ?
Now illuminate it under red light. The paper is now orange, but the banana is still yellow!
Colour perception is very much an ART, not a science (well, it is science, but it's random and statistical, not exact).
Cheers,
Wol
Hughes: Introducing the ColorHug open source colorimeter
Posted Nov 15, 2011 0:18 UTC (Tue) by nix (subscriber, #2304)
[Link]
This is, of course, an example of *consistent* colour perception. The frequency mix of the light reflected from the banana has changed, but the *colour* is the same, because 'colour' is a thing entirely situated within the brain, and is corrected to a large degree for lighting conditions, shading, surface texture and much else. (Nothing we can build can do such a good job, let alone do it in realtime with noisy, constantly jittering input from input sensors laid out partly at random.)
stochastic sensor placement
Posted Nov 15, 2011 14:30 UTC (Tue) by tialaramex (subscriber, #21167)
[Link]
The "input sensors laid out partly at random" is actually a clever trick, which we do in fact use in things we build although not cameras so far as I know. The sensors are in fact arrayed stochastically, which inherently avoids artefacts like aliasing.
Suppose you're looking at, for example a distant checkerboard pattern. If you use a perfect rectangular grid of sensors at certain distances, you will "see" patterns that don't really exist because of the regularity of your sampling. If you instead "randomly" place the sensors according to a rule that limits their proximity you completely avoid this problem.
Pixar's Photorealistic Renderman (and presumably many other modern 3D rendering systems) likewise uses multiple stochastically chosen sample origin points for each pixel, with the same result - no aliasing.