| |||||||||||||
Hughes: Introducing the ColorHug open source colorimeterHughes: Introducing the ColorHug open source colorimeterPosted Nov 14, 2011 15:23 UTC (Mon) by epa (subscriber, #39769)Parent article: Hughes: Introducing the ColorHug open source colorimeter
Great news. I've been meaning to calibrate a few monitors but I didn't want to shell out for a proprietary colorimeter with its restrictive driver software. Reading the description of the device it's simpler than I had expected. I suppose the secret is to make sure you have exactly the right shade of red, blue and green in the colour filters and that you know exactly what proportion of incoming light they let through.
Hopefully, too, there can be a database of colour profiles for common monitors which can be included with Linux distributions. Yes, every individual monitor is different and should ideally be calibrated individually; but still a general profile for all monitors of a certain type is better than no profile at all.
Perhaps the LiveCD software could ask if you want to submit your profile to a central database.
(Log in to post comments)
Hughes: Introducing the ColorHug open source colorimeter Posted Nov 14, 2011 16:18 UTC (Mon) by slashdot (guest, #22014) [Link]
Isn't it much better to simply make monitors that correctly output the sRGB colorspace instead of being broken and requiring calibration?
Hughes: Introducing the ColorHug open source colorimeter Posted Nov 14, 2011 16:32 UTC (Mon) by zlynx (subscriber, #2285) [Link]
Many of the more expensive monitors are calibrated after production and so they are "correct" as far as that goes.
I believe the problem comes in because the monitor also reflects some of the light in the room back at the viewer. This changes its color profile.
So to get the monitor perfectly calibrated you need to calibrate with the room lighting set up just as you would be using it.
Hughes: Introducing the ColorHug open source colorimeter Posted Nov 14, 2011 16:45 UTC (Mon) by mattdm (subscriber, #18) [Link]
It seems unreasonably idealistic to hope that all displays would ship calibrated to any standard. However, sRGB in particular would be a very limiting choice since it is a rather restricted space.
It's okay as a fallback "safety", but by design it's a lowest-common-factor. Restricting all hardware to that would keep us from taking advantage of better hardware and getting the most out of new display technology.
By working with a color-calibrated device in the first place and using a color-managed workflow, you can take advantage of better hardware and be reasonably certain that the images you create will render decently on a "non-broken" default-sRGB device.
Hughes: Introducing the ColorHug open source colorimeter Posted Nov 14, 2011 16:58 UTC (Mon) by renox (subscriber, #23785) [Link]
> 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?
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'
How so?
As far as I can tell, you can get CIE XYZ values by integrating a measured light distribution (after a constant linear transformation) weighted with the functions at http://en.wikipedia.org/wiki/File:CIE_1931_XYZ_Color_Matc..., convert to linear RGB via the matrix multiplication at http://upload.wikimedia.org/wikipedia/en/math/b/d/2/bd2b2... and finally each component to sRGB with the formula at http://upload.wikimedia.org/wikipedia/en/math/c/d/e/cde58...
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,
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.
Hughes: Introducing the ColorHug open source colorimeter Posted Nov 16, 2011 1:17 UTC (Wed) by ringerc (subscriber, #3071) [Link]
sRGB is horrible. It was designed as the least-common-denominator colour space for *CRT* monitors. Not only is it a narrow crappy gamut, but it's inappropriate for LCD displays.
In any case, unless you bought a rather high end display designed for colour work, your monitor won't be factory-calibrated for sRGB, it'll have a canned set of pixel gains pre-configured for the entire production run. At best these will be inaccurate; most of the time they're totally bogus.
sRGB is not the answer unless you do no colour-sensitive work whatsoever. Even then, it's ugly.
|
|||||||||||||
