WinDAS White Point Balance guide for Sony Trinitron CRTs

here's some super simple code for reading the LUT:
http://pastebin.com/5H1pVpTg

interestingly, dispwin -c doesn't restore the original LUT that windows boots with. the original LUT is
0,1,2,...,254,255
->
0, 256, 512, ..., 254*256, 255*256

diswin -c makes it
0,1,2,...,254,255
->
0, 257, 514, ..., 254*257, 255*257.

as 255*257 = 65535, this covers the entire range of 0-65535.

from what I understand, getdevicegammaramp and setdevicegammaramp are just wrappers for whatever lower level function provided by the graphics driver for adjusting the actual lut.
 
I see what you mean. But what if you only were interested in collecting light from, say, a third of the screen area, so you could use a smaller "dish"? As it is, our instruments collect light from a pretty small area, so one might not need to focus light from the entire screen to get a measurable boost.

thought about this, but if you make it too small the size of the colorimeter would block a significant amount of light.

3rd idea: just use a dslr to measure luminance... 30second exposure time at the highest iso should do the trick. i'm pretty sure that the raw file contains luminance information stored linearly. averaging across the whole frame would kill noise by about 1000 times

fun with SetDeviceGammaRamp:
adding this to the code:
vals[1][100] = 40000;
vals[1][95] = 10000;

if (SetDeviceGammaRamp(hdc, vals) == 0) {
printf("fail set!\n");
return 1;
}
it works ;d
http://i.imgur.com/gDlmKgh.jpg

so it doesn't have to be monotonically increasing.
the only limitation is
[url said:
http://msdn.microsoft.com/en-us/library/windows/desktop/jj635732(v=vs.85).aspx][/url]
These APIs, in contrast to the others described later in this section, allow only a small deviation from an identity function. In fact, any entry in the ramp must be within 32768 of the identity value. This restriction means that no app can turn the display completely black or to some other unreadable color.
 
Last edited:
here's some super simple code for reading the LUT:
http://pastebin.com/5H1pVpTg]

heh, maybe this will motivate me to learn c. I know next to nothing about programming. I don't know what object oriented programming is, or what a wrapper is. I only know matlab :p


interestingly, dispwin -c doesn't restore the original LUT that windows boots with. the original LUT is
0,1,2,...,254,255
->
0, 256, 512, ..., 254*256, 255*256

diswin -c makes it
0,1,2,...,254,255
->
0, 257, 514, ..., 254*257, 255*257.

as 255*257 = 65535, this covers the entire range of 0-65535.

If that's the case, that would mean that peak luminance with the default LUT would be lower than with dispwin -c, right?

from what I understand, getdevicegammaramp and setdevicegammaramp are just wrappers for whatever lower level function provided by the graphics driver for adjusting the actual lut.

ok now I'm getting a hint of what a wrapper is. But isn't everything in code just a wrapper unless you're programming in machine code?
 
thought about this, but if you make it too small the size of the colorimeter would block a significant amount of light.

3rd idea: just use a dslr to measure luminance... 30second exposure time at the highest iso should do the trick. i'm pretty sure that the raw file contains luminance information stored linearly. averaging across the whole frame would kill noise by about 1000 times

Interesting idea. I was thinking of investing in a dslr at some point in the future. Not sure how accurate the luminance filter is in a dslr, but it might be simple to compare the dslr's reported luminance against the colorimeter's reported luminances at higher levels, and see if any scaling factor is needed.

fun with SetDeviceGammaRamp:
adding this to the code:

it works ;d
http://i.imgur.com/gDlmKgh.jpg

so it doesn't have to be monotonically increasing.
the only limitation is

See this post

and then this one.

The info is a few years old, but it might still be valid.
 
a dslr doesn't measure luminance directly. the best output you'll get is a raw file with 10bit or so numbers.

if money is no issue, we could just use these
http://www.thorlabs.com/newgrouppage9.cfm?objectgroup_id=5255

:DDDD


about the limitations:
did some testing that confirms what microsoft describes... which is what that guy found in the second link

basically this is the rule:
4uFf3PL.png


for me, that's more than enough freedom for testing
 
Last edited:
ok those constraints aren't as bad as I thought. that thorlabs site is pretty cool.

If I had the cash, I might get a Klein K10-A

reads as low as 0.00006 cd/m2 :)

Do you have a dslr you can experiment with?
 
no but I may be able to borrow one this weekend

I wrote a little command line program for quickly adjusting the lut in windows
source: https://gist.github.com/FloooD/e653137600967759cfea
binary: http://www.filedropper.com/lutadjust
(not that you shouldn't trust me, but please always scan any executable file you download with whatever antivirus you use and/or virustotal.com)

run the program without any arguments for usage instructions.

examples of everything you can do with it:

>lut_adjust c
sets lut to default windows state (0,256,512,...)
>lut_adjust c 257
does what dispwin -c does (0,257,514,...)
>lut_adjust c 200
sets lut to 0,200,400,600,...

>lut_adjust g b 123
prints the lue lut value for an input of 123
>lut_adjust g a 123
prints [a]ll three lut values for inputs of 123
>lut_adjust g r
prints the entire [r]ed lut
>lut_adjust g a
prints [a]ll three lut's

>lut_adjust s b 0 10000
ets the lue lut to map 0 to 10000. this causes black to look dark blue.
>lut_adjust s a 0 10000
ets the [a] three lut's to map 0 to 10000. this causes black to look gray.


i should note that I'm not sure how it behaves with multiple monitors. probably it adjusts the lut of the main monitor......
 
nice work! will use ur program to do that peak lum check (between windows default and the full "c" range)
 
just figured out how to keep the LUT unchanged in csgo (launch options: -nogammaramp)

guess that means I'll be doing another wpb tonight and have fun with super dark blacks.

hm i should make the program able to read input files...
 
Last edited:
like a file with

0 0 0
256 256 256
512 512 512
...

so basically my own version of argyll's .cal file
 
heh, maybe this will motivate me to learn c. I know next to nothing about programming. I don't know what object oriented programming is, or what a wrapper is. I only know matlab :p
c would be pretty simple to learn.. just read k&r (google k&r pdf)
dont worry about oop, imo it's not really useful unless you want to make "actual" software :D
If that's the case, that would mean that peak luminance with the default LUT would be lower than with dispwin -c, right?
just measured in hcfr; yes dispwin -c does make the screen brighter than what it is at boot.
ok now I'm getting a hint of what a wrapper is. But isn't everything in code just a wrapper unless you're programming in machine code?
[/quote]
yea sorta...
 
just measured in hcfr; yes dispwin -c does make the screen brighter than what it is at boot.

very interesting, and strange. And important with respect to the WPB guide. In my next revision I'll instruct users to use the dispwin -c before they begin the WinDAS procedure, else they're gonna end up with higher luminances after the Argyll adjustment.

Why on earth would windows truncate the default LUT??
 
because this:
i just checked and basically for my setup (old gtx 460, windows 8, nvidia 337.88 :p), the output of the ramdac has exactly 1024 levels i.e. 10bit precision.

windows default results in the actual lut curve being completely smooth
as in
0 -> level 0
1 -> level 4
2 -> level 8
...
255 -> level 1020

the increments are always 4 levels.

dispwin -c results in more quantization errors. most times the increment is 4 but 3 times it's 5.
0 -> level 0
1- > level 4
...
63 -> level 252
64 -> level 257
65 -> level 261
...
127 -> level 509
128 -> level 514
129 -> level 518
...
191 -> level 766
192 -> level 771
193 -> level 775
...
254 -> level 1019
255 -> level 1023

for calibration, since the lut won't have uniform steps anyway, probably it's preferable to use the maximum possible level, which is what argyll does when dispcal is ran.

it's only a 0.6 nit difference between the default and dispwin -c so I don't think it's a big deal to change it before wpb.
 
great detective work, sir. btw how were u able to determine the precision of the RAMDAC? was it using the same method I used here?

maw2ok.jpg
 
ya basically.
I looked for the boundaries where changing the lut by 1 and found that they were all spaced apart by exactly 64
 
is there any automated way for hcfr to display and measure grayscale with a single button?

(i guess argyll dispread can, but i'm lazy and want the instant plot of rgb levels that hcfr provides


edit:k got it

measures>generator>select>view images
and then configure it since the default is only a small patch
 
Last edited:
what do you mean by "scale"? Scale of what?

What's the problem with those images? Can you be more specific?

btw I think preset contains settings from previous custom adjustments. As far as I know, best to just stick with easy.
 
hm a dslr isn't necessary, though it would be better as they tend to have larger sensors (more sensitivity for the same amount of noise)

i think I'm going to get one of those casio high speed cameras which do raw (ex-zr700 is the cheapest one i think)


noise and ambient light will definitely be an issue and contribute to a background level. one way i can think of to handle this is to take pictures of the monitor when it's shut down completely. that should provide a baseline for the ambient level + noise.
 
Last edited:
doubt it but I dont see why that would be important

edit:
k lets move technical camera discussion to that thread in the photography forum
 
Last edited:
got my ex-zr700. will start testing tonight :D
though i just realized I need to get some sd card and maybe a small tripod
 
awesome! I was just thinking about this an hour ago, wondering who'd post first on this thread :)

Today someone had a DSLR at the lab but I didn't have time to ask to borrow it - will try tomorrow. Looking forward to your discoveries!
 
haven't looked at any RAW files yet but from some initial tests it seems the limit of this camera is around 10^-4 nits

using the in camera lighting adjustment, it can easily see my iphone's black with backlight at minumin, which is around 0.005 nits. (dtp 94 measures as 0.01 but the white level with backlight at minimum is around 4nits and the contrast ratio is ~1000:1)

anyway the first issue right now is to reduce ambient light in my room.. there's quite some light leaking through my blinds

update:

okayyyyyyyyyyyy good news

with the raw files, the camera can see the darkest blacks my crt can possible produce.

iso 100, 15s exposure. this is what's outputted by dcraw:

http://i.imgur.com/iOnmY85.jpg

I calibrated with a low g2 and then set brightness to 0 for this picture of a completely blank screen. the geometry is shrunk so that there's a significant unscanned region under the scanned region.

top somewhat green tinted region is the scanned region
then there's the dark unscanned region underneath.
on the left you see my index finger
the green thing is the reflection of the power led off my thumb nail
on the bottom is the bezel and you can just barely make out the "ony" from the sony logo....



basically this means that this camera (and probably any other point+shoot that can capture raw images) is sufficient for calibrating the darkest colors a crt produces. erm... at least for my cpd-g520p... maybe others can be even darker
 
Last edited:
wow, good stuff. I'm surprised that the unscanned region seems to be lighter than the scanned region!

The real test will be to see whether those same camera settings can produce a non saturated image at measurable luminances.

Also, does the camera allow viewing of the RAW file before demosaicing?
 
So I might be able to borrow a Canon EOS Rebel XSI this evening (shoots 14 bit RAW). Hopefully I'll be able to get something useful out of it.
 
wow, good stuff. I'm surprised that the unscanned region seems to be lighter than the scanned region!

The real test will be to see whether those same camera settings can produce a non saturated image at measurable luminances.

Also, does the camera allow viewing of the RAW file before demosaicing?

wait wut

these are the regions:
http://i.imgur.com/cxehiQ8.jpg

the unscanned part is a few levels darker than the scanned part

ya the camera saves both a raw file and a jpg
 
oh doh I mistook bezel for unscanned region :)

What software are you gonna use for the RAW files? I hear lightzone is good.
 
plan is to use dcraw to output a linear tiff file and then matlab to calculate averages and uncertainties

with a dslr that can do long exposure times, you can probably take very clear pictures in the dark.
 
just got home, and have the Canon with me. Also picked up an sd card reader on the way back.

Gonna experiment with raw files first, just to make sure I can output a 14 bit linear tiff that hasn't been demosaiced.

edit: only had 10 min to experiment, but so far haven't been able to figure out how to use lightzone to stop from demosaicing. Gotta leave for a couple hours will try when I get back. Lemme know if u have any luck with dcraw. Ideally we want only the green channel from the mosaic'ed image.
 
Last edited:
Back
Top