1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
{\rtf1\mac\ansicpg10000\cocoartf102
{\fonttbl\f0\fnil\fcharset77 Monaco;}
{\colortbl;\red255\green255\blue255;}
\margl1440\margr1440\vieww26500\viewh15420\viewkind0
\pard\tx480\tx960\tx1440\tx1920\tx2400\tx2880\tx3360\tx3840\tx4320\tx4800\tx5280\tx5760\tx6240\tx6720\tx7200\tx7680\tx8160\tx8640\tx9120\tx9600\tx10080\tx10560\tx11040\tx11520\tx12000\tx12480\tx12960\tx13440\tx13920\tx14400\tx14880\tx15360\tx15840\tx16320\tx16800\tx17280\tx17760\tx18240\tx18720\tx19200\tx19680\tx20160\tx20640\tx21120\tx21600\tx22080\tx22560\tx23040\tx23520\tx24000\tx24480\tx24960\tx25440\tx25920\tx26400\tx26880\tx27360\tx27840\tx28320\tx28800\tx29280\tx29760\tx30240\tx30720\tx31200\tx31680\tx32160\tx32640\tx33120\tx33600\tx34080\tx34560\tx35040\tx35520\tx36000\tx36480\tx36960\tx37440\tx37920\tx38400\tx38880\tx39360\tx39840\tx40320\tx40800\tx41280\tx41760\tx42240\tx42720\tx43200\tx43680\tx44160\tx44640\tx45120\tx45600\tx46080\tx46560\tx47040\tx47520\tx48000\ql\qnatural
\f0\fs20 \cf0 \CocoaLigature0 \
This file suggests three changes to the PTB:\
1- Internally we represent color values as normalized doubles in the range 0-1\
2- Internally we represent video display modes with enumerated types instead of structs.\
3- We migrate Screen to accepting normalized pixel values in the range 0-1 instead of actual register values by providing a preference switch for that. \
\
\
Internally, the OS X PTB represents the video mode in an overcomplicated way, using a struct with separate fields holding numeric values describing color and depth resolution. It encodes the resolution but fails to capture the format- the order of planes within a pixel, for example GBRA vs. RGBA. We can improve on that by representing a pixel formats using an enumerted type instead of a struct of values, though the transition would require major surgery.\
\
The ugliness of the present system is that we end up passing the pixel format stuff around a lot, partly because Screen subfunctions accept ambiguous arguments which are resolved using the pixel format. Pixel format information must accompany a color triplet if we use non-normalized color values, for example 4 is ambigous, being either 4/256 or 4/1024. OpenGL wants the normalized value. So it would be much cleaner also if we used normalized pixel values internally throughout. If we normalize input color values upon receipt from MATLAB into the Screen we never (or rarely) need to resolve those to non-normalized values to register values because unlike QuickDraw, OpenGL wants normalized values in the range 0-1. \
\
Various random To Do comments: \
\
\'a5 Create a surface descriptor of enumerated types with each constant denoting attributes depth, plane size and order. For examle: kPsych_R8_G8_B8_A8. This covers order, size, and number of planes and it's a single constants, so we only need to pass one value around when that is required. If we want to get fancy we can write a layer of extractors, for example:\
\
PsychGetNumPlanes(kPsych_R8_G8_B8_A8)\
\
would return 4\
\
Othewise we would need big conditional statements all over the place. \
\
\'a5 Internally pass around all RGB values as values normalized to the range 0-1. OpenGL accepts such normalized values as floats or doubles, so we don't lose anything or introduce sloppyness by doing this in the PTB also. Convert them to this format and store them this way as soon as they received by the PTB from MATLAB. Write functions to munge the normalized values into the values in the range appropriate for the depth mode constants. \
\
\'a5 Normalizing stuff should prevent us from needing the depth every time we want to do something with the color, so we don't need to tie depth information to color information, which saves a bunch of work. \
\
\'a5 Include a preference flag for when using RBG values in the range of 0-1 or 0-2^bitDepth and use it when allocating in values. Note that there is an interaction with 8-bit indexed mode here. \
\
\'a5 We could provide a preference for the PTB in MATLAB for accepting normalized values and interpret numeric values immediately upon receipt, in functions which read in color arguments passed to screen from MATLAB. There would be little work in doing this. The gripe about this is that the color precision is not explicit and may be forgotten, but so long as it can be queried, what's the problem? Plus, changing the numeric range of values in your program based on color resolution of the hardware is a real headache. Importanly, it allows us to interact OpenGL more transparently. The system of non-normalized color values will aggravate anyone with an OpenGL background who is trying to use the PTB. \
\
\'a5 I think the reasons that the OS 9 PTB does not use normalized color values are 1. Its based on QuickDraw which does not. 2. Doing so forces the user to be aware of the underlying resolution. With OpenGL, 1 No longer applies and I don't believe that 2 works for the people who need it or is useful for the people who do not. If you are not aware of the issue of false resolution and hidden quantization, is explicit quantization going to clue you in to the problem? Quantized resolution should be easily queryable in the PTB but do we need to inconvenience the user to make the point?\
\
\
Allen Ingling\
28 October 2004\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
}
|
