[mflaster]

Edit: This is embarassing. Don't read this thread!!! Skip to the bottom - it turns out my projector was too green!


I'm seeing some odd behavior with my modified Davis DLX650 clone.


Originally, with ColorFacts' Optimagery sensor, I measured my white point - and it said it was way too green. In order for the sensor to report that I had a relatively balanced color, I had to put up something which was *very* PINK .


So I upgraded to the Eye-One sensor. This is a full spectro-radiometer, after all. Well, guess what - it *also* says my projector has too much green. It doesn't make sense to me that two completely different devices would both say I have too much green - and yet my eyes say it's pretty white. If I put up RGB (255,190,255), which looks pink, the sensor says it's white.


Here's some info from a white field - 255,255,255:
http://www.flaster.net/images/white_spectrum.gif


You can see that the sensor thinks the RGB is 100, 132,100 - i.e. 30% too much green. And yet when I calculate the temperature, using a
CCT Algorithm I downloaded, I get 6367, which seems pretty close to 6500. The xyY readings are also shown - pretty far off from D65...


So I have a few questions:

1. Is it correct that a normal person would have a hard time distinguishing between a white point of 6367 and D65 by eye? Especially without a reference point. i.e. if you look at a 6367K white, it would look pretty white, not pink, correct?
2. Could a color that looked distinctly *non* white to the naked eye map to a 6500 color temperature? These temperatures are just shortest distance to that black-body color loci. They're meant to describe near-white colors. So - is there any pink color, that if you tried to calculate a color temperature, you could get 6500K? In other words, if I calculate a 6500K temperature, is that sufficient to show my color balance is correct?
3. Mapping to RGB seems to be an unscientific thing. Is that the best way to figure out how close your R/G/B balance is to D65? Or is color temperature a more accurate way to represent how white it looks to an observer?[/list=1]
   
   
   I guess to summarize. My white looks pretty white, but the sensor, when measuring in RGB mode, says it's not white at all. Is there definitely something inconsistent with the sensor readings and my perception of the color? Is there a better measurement to take (e.g. uv, Ch, Chuv, LABmg, LCHmg - don't know what these are) to see color balance?
   
   
   Thanks!
   
   
   Mike

 

[maxleung]

That is very surprising. I would have thought that the less expensive sensors (like the old Progressive Labs CA-1) would report odd readings only because they were calibrated for CRT phosphors, and not DLP projectors. Uh, I am assuming that your Davis is a DLP of course.


The Eye-One...it is a true spectroradiometer right? That is very strange indeed. Are you measuring from the screen or directly from the projector lens?


It is possible that your calibration software needs to know what type of projector you are using, though.

 

[Mark Hunter]

Mike,


Did you try the same thing using ColorFacts? I've never seen this program pictured before.


The main reason I ask is because the "Dark Reading" in ColorFacts is a very essential pre-requisite to taking a color reading. Also, if you have the source code for this program, I have some things you should check regarding the math.


At any rate, try the test with the ColorFacts software and e-mail me the results.

 

[Guy Kuo]

I would expect the ColorFacts + i1 to read the color correctly independent of any calibration file. By any chance did you forget to set the target white point in Colorfacts to D65? It doesn't default to that automatically when first used. That can give some really odd results until you realize the program's targeted white point isn't the D65. Mark's point about doing a dark reading prior to actual measurments is also important.

 

[mflaster]

Quote:

Originally posted by maxleung Uh, I am assuming that your Davis is a DLP of course.

Yes, it's a DLP. The modifications that have been done to it are to block the clear section, and also, this is a bit unusual, add a green filter directly to the green section of the color wheel. This was done to try to slightly reduce the green output (like 5%). It would seem that this should make the green spectrum narrower. I didn't see the green spectrum without the filter, but now it does indeed seem to be narrow.

Quote:

Are you measuring from the screen or directly from the projector lens?

Mainly from the screen. If I point it directly into the lens, if I'm too close to the projector, I'll get overflow errors - I guess too much light. But I believe I did take some readings directly into the projector which also showed too much green.


Mike

 

[mflaster]

Quote:

Originally posted by Mark Hunter Did you try the same thing using ColorFacts? I've never seen this program pictured before.

You're correct, this is software I wrote myself. Where's the fun in using software that's already written?

Quote:

The main reason I ask is because the "Dark Reading" in ColorFacts is a very essential pre-requisite to taking a color reading. Also, if you have the source code for this program, I have some things you should check regarding the math.

I did do a 'calibrateOnDark' before taking readings. As far as the math goes, for one measure of RGB, I'm just telling the sensor to report "RGB" instead of xyY... I also put in some of my own math for computing RGB (downloaded from the internet), and it pretty much matches the RGB values that the sensor reports.

Quote:

At any rate, try the test with the ColorFacts software and e-mail me the results.

OK.


Mike

 

[mflaster]

Quote:

Originally posted by Guy Kuo I would expect the ColorFacts + i1 to read the color correctly independent of any calibration file. By any chance did you forget to set the target white point in Colorfacts to D65? It doesn't default to that automatically when first used. That can give some really odd results until you realize the program's targeted white point isn't the D65. Mark's point about doing a dark reading prior to actual measurments is also important.

I will check that I'm setting D65 as the white point - I don't have the code in front of me now.


One important point that I forgot to mention (doh!) is that I first did all my testing/development on my LCD monitor, and everything worked fine. The sensor/software seemed to quite accurately report the color balance, and the white point was fine.


This was the same behavior I saw with the Optimagery, tri-stimulas device. It correctly showed the white balance on my LCD, but on my projector was too green.


So that's why I was thinking there was something deeper at work here.


Let's say you have a light source which is relatively flat/spread out for red and blue, but is a laser/single wavelength for green. Could that confuse the readings? You can see that my peak in green is much higher than the other colors - but theoretically it's much narrower. I believe the i1 measures in 2.5 nm bands, and reports them in a combined 10nm band. Is it possible that somehow the way it integrates the curve doesn't exactly match what your eye sees?


Or put another way - if I remove the filter (remember this filter is *only* on the green part of the color wheel - it is physically attached to the color wheel), I believe there will indeed be too much green. Is it possible that by adding the filter, and narrowing the green spectrum, the effect on my eyes is different than the effect on the spectroradiometer?


Mike

 

[Guy Kuo]

The way the i1 sensor overlaps its sensor bands should allow it to integrate the light properly even if there are narrow spikes in the source. The observer curves are fairly smooth curves so the bands being in 10 nm increments shouldn't be making as big a difference as you are observing. I can't explain your observations as yet.


BTW, kudos on rolling your own software to interrogate the i1.

 

[wm]

Mike,


To answer one of your questions (#2), it is possible to have a very green image and still have the CCT be 6500 K. I have demonstrated this many times. If the coordinates that your first readout shows are in fact the accurate CIE 1931 xyY coordinates, then then the whites should indeed look green.


Send me an email and we can compare notes on our software (I have my own as well, which supports the CA-1, Lightspex, Eyeone, and a couple of other devices). Perhaps we can spot something different about the way we are talking to the EyeOne. I also have a Gretag Lightspex for reference, and in general, if the a darkframe has been taken quite recently, and readings are taken of light reflected from a screen, and the light level is high enough, the Eyeone does a pretty good job. But that's a bit of a list of if's...


To your question #1 - this cannot really be answered because the 6367 is a Correlated Color Temperature, and is not enough information to tell us what it really looks like. D65 is a specific set of xy coordinates, and DOES tell us what the color is.



William

 

[maxleung]

*smacks head* William, you are absolutely right, and I can't believe I didn't think of it! Hours spent with my CA-1 should have reminded me that you can have non-white colors that still read as 6500K!

 

[mflaster]

Thanks for the replies.


William -


When I wrote the software, there were definitely some API calls/concepts I wasn't sure about. (The following is from memory, I don't have my code in front of me.) The manual seems to list all these different interfaces, but the sensor only reports that it supports SpecPhotoMeterEmission and TristPhotoMeterEmission. The way my software works, is on startup, it creates both of those interfaces. It then asks you to calibrate. I call calibrateOnDark on both interfaces (I believe). Then later on, depending on what button is pushed, I use the appropriate interface.


(I actually just read in the manual: "Calibration methods of different interfaces shall not be combined as this may lead to incorrect measurement results." I'm not sure what that means.)


As I've said, my software works for my LCD. Maybe there's some subtle error which causes it to not work for all display devices?


One thing I don't understand - how can the Eye-One report RGB values from 0 to 255, when it has no idea what the range of output of the device is? In other words, I would think that RGB of (0,0,100) and RGB of (0,0,200) would have the exact same x,y coordinates, and only Y would differ. So if the sensor sees all blue, and a Y of say 10, how does it figure out what the B value is? There doesn't seem to be any kind of 'measure primaries' in the API.


Mike

 

[wm]

The RGB values are scaled. The CIE coordinates are computed from the spectral reading using CMF's (color matching functions). UC San Diego has an excellent discussion of this on their web site (or did have). With a full spectrum device you don't need to measure the primaries.


Add a button to your tool to take a new dark frame (with the probe covered, of course). See if that makes any difference.


William

 

[Mark Hunter]

Mike,


IMO, forget RGB for now. Work only in xy (color independent) color space for your testing. You are right that the RGB values reported by the driver are probably not correct for your device.


William has a good idea with the dark frame button. That should help.


Mark

 

[mflaster]

Well, I made some slight adjustments, I calibrate frequently, but still no luck. Here is a spreadsheet which has the raw data for the sensor, for when I measured white (with a very green-looking x,y coordinate even though to my eye it's white), and also when I measured the primaries. The sum of the primaries pretty closely matches what white reads, so that's good.


One thing - for the measure conditions, I only set the observer key (2 degrees) and the illumination key (D65). I am not setting the white base key, the density standard key, the density filter mode key, or the filter key. I'm using the C++ interface, so I assume they default to good values (I believe in their demo app they don't set them either) - and I don't know what any of these settings mean. I guess I could try randomly changing all the settings - but does anyone know what they mean? Could any of them cause such a big shift in x,y coordinates? (Of course remember the shift/mistake occurs only on my DLP, not on my LCD...)


I should really try ColorFacts already!!! But it's too late tonight...


Mike

 

[mflaster]

Could polarity of the light cause some kind of issue? I'm wondering if the green filter on my green section is somehow polarizing the light, while my R & B sections would not be polarized. I wonder if that could confuse my instrument.


Does polarity have any kind of effect on spectroradiometers? There are settings having to do with filters and polarizers, so maybe they're somehow important...


Mike

 

[mflaster]

Well, this is rather embarassing...


I tried ColorFacts, and it also showed that the projector was too green. So I bought a polarizing filter, and it didn't effect any readings.


When I bought the polarizing filter, I also bought a CC25M filter. I was thinking if I ever remove my green filter from my color wheel, I'll filter the whole light output.


So there I was, with measurements saying my projector was too green. So I stuck the CC25M filter in front, and it indeed looked pretty pink. Then I looked down, and looked up, and - presto! The picture looked fine! I couldn't believe my eyes.


I took the filter up and down, and looked at the difference. It soon became clear to me that for the entire 3 years that I've owned a projector, I've always watched a picture that was too green!


The one thing that was interesting, which might benefit others - even though the green was off by 25% - this is not really noticeable to the untrained eye with no reference point. I never noticed, and none of my guests ever noticed.


But wow, my projector looks so much better now!


Now I'm playing with filters - here's a thread I posted with my measurements of the filter. Maybe others can measure their filters too.


Mike

 

[Dan Miller]

To re-emphasize what WM said...


You would be shocked at how many different colors can measure a CCT of 6500k. It can be all the way toward pink as well as green.


You GOTTA stick to XY.


As far as filters go, they can work, but many times will affect the spectral balance of white. Even a color correction filter for a certain color will many times do SOMETHING to the others as well.


In the ideal world, if you could get a filter that had all three primaries (when being fed independently with RGB signals, so no color decoder issues will take place) ending up at (or outside, with a straight line from the point being measured, through the reference, and ending up at D65) ATSC primary colors, then you could use bias and gain settings to get an accurate greyscale. Of course, unless you have a dead nuts accurate color decoder and no other circuitry playing with color, you will only see the results with an RGB input.


And this gets to the root of the problem of second guessing the designers of these devices. I understand and totally get the desire to tweak. But I am constantly shocked and amazed when I ask questions of Japan only to find out that they had the same question and came to conclusions 2 YEARS ago... Determining the colors of the filters on the color wheel, based on aged bulbs and the color of light that they yield, and then designing the rest of the PJ to compensate for any resulting errors is a MONSTER job.


I'm not suggesting that you don't try to tweak and improve things... I do all the time. But the one advantage(?) that I have is that every time I think I've made a significant improvement, I email Japan, and they tell me, "yeah, we tried that but if you look at so-and-so, you'll see why we didn't use it", and I end up back at a pretty much bone stock condition...


Just my two cents...


DM

 

[Thumper]

Mike,


The Davis has somewhat unique color wheel sectors; with unequal sizes. Each color slice makes up a different percentage of the wheel. I'm not sure exactly how Colorfacts times/coordinates it's sampling routine but the significantly non-equal segments verses sampling rate may have something to do with the odd readings.


Thump

 

[mflaster]

Hey Thumper, good to hear from you!


Actually, at this point, I'm pretty convinced that the Eye-One was reading the spectrum correctly - it was my eyes that didn't work!


Dan - I think one exception to what you're saying is when the projector was *not* originally targetted for the home theater market. The Davis I have is really more meant for presentation. So the extra green makes it a lot brighter, and certainly during presentations the color wouldn't be noticeably off.


Mike

 

[Dan Miller]

Absolutely... green is the brightest of the colors as it is, comprising roughly 51% of white... so whatever you do to it will affect the brightness visibly.


I was speaking primarily of ours...


DM