[OpenGL/GLUT] incorrecte kleuren

[Verwijderd]

Ik ben bezig een kleur-calibratie programmaatje te schrijven, maar heb wat problemen met de kleuren die ik aanbiedt. Als er bijvoorbeeld (7,0,0), (15,0,0), ..., (255,0,0) wordt aangeboden dan word de stimulus na ongeveer (95,0,0) geleidelijk steeds 'lichter' rood (meer gesatureerd?) en lijkt bij (206,0,0) plots weer donkerder (minder gesatureerd?) te worden. Hetzelfde gebeurt bij groen en volgens mij ook bij blauw (hoewel het daar iets minder sterk lijkt).

Initialisatie gebeurt met:

glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_ALPHA| GLUT_DEPTH);

(sorry, ik weet niet hoe je van die mooie code-boxjes maakt :-))

Ik heb de GLUT_ALPHA als 's weggehaald, net als de GLUT_RGBA (en ook al GLUT_RGB geprobeerd), maar dat helpt allemaal niks.

Setten van de kleur met:

glColor3ub(R,G,B) // ub == unsigned byte

Hij lijkt wel in 8-bits mode te staan, want als er bijv. (263,0,0) wordt aangeboden wordt het groen ipv rood.

Wie-o-wie weet waar het aan zou kunnen liggen? Bij voorbaat dank iig.

PS: volledige code is over een paar minuten te vinden op http://129.125.220.228/other/calib_stim.c
en http://129.125.220.228/other/calib.zip (incl. makefile)

[.oisyn]

krijg je hetzelfde als je glColor3f gebruikt met ranges 0.0...1.0 ?

[Verwijderd]

.oisyn schreef op 23 maart 2004 @ 22:38:
krijg je hetzelfde als je glColor3f gebruikt met ranges 0.0...1.0 ?

Ja, helaas wel ... exact hetzelfde

Ik denk dat het iets heeft te maken met initialisatie o.i.d., maar heb tot nog toe niet uit kunnen vogelen wat ...

[.oisyn]

Er was zo'n manier om voor waarden scale en een bias mee te geven voor ze gestuurd werden naar de grafische kaart (of terug). Even kijken wat dat ook alweer was...

.edit: ah, dat ging met glPixelTransfer, maar die heeft volgens de docs alleen maar invloed op glCopyPixels, glCopyTexImage1D, glCopyTexImage2D, glCopyTexSubImage1D, glCopyTexSubImage2D, glDrawPixels, glReadPixels, glTexImage1D, glTexImage2D, glTexSubImage1D en glTexSubImage2D.

Doe je hier toevallig iets mee?

[ Voor 50% gewijzigd door .oisyn op 23-03-2004 23:54 ]

[Verwijderd]

Doe je hier toevallig iets mee?

Bedankt voor de tip, maar nee, daar doe ik niks mee. En het is eigenlijk ook niet de bedoeling om bias e.d. te gaan invoeren, omdat het een kleur-calibratieprogramma betreft en ik juist de 'ruwe' RGB-signalen wil meten. Ik wil dus de R, G en B-kanonnen doormeten en kijken wat voor output ze geven (in CIE-space; een gestandardiseerde kleurruimte) voor de range [0..255]. Maar het lijkt erop dat in m'n programmaatje (http://129.125.220.228/other/calib_stim.c) iets anders dan [0..255] naar de display device wordt gestuurd (ik heb het programmaatje ook op een andere PC gedraaid en daar gebeurt precies hetzelfde; het ligt dus waarschijnlijk niet aan de display device zelf). .

[.oisyn]

Dat snap ik, maar ik bedoelde dat ze wellicht verkeerd stonden ingesteld. Maar goed, dat is natuurlijk allemaal niet relevant als je niet met een van die functies werkt

[Korben]

Verwijderd schreef op 23 maart 2004 @ 21:42:
Ik ben bezig een kleur-calibratie programmaatje te schrijven, maar heb wat problemen met de kleuren die ik aanbiedt. Als er bijvoorbeeld (7,0,0), (15,0,0), ..., (255,0,0) wordt aangeboden dan word de stimulus na ongeveer (95,0,0) geleidelijk steeds 'lichter' rood (meer gesatureerd?) en lijkt bij (206,0,0) plots weer donkerder (minder gesatureerd?) te worden. Hetzelfde gebeurt bij groen en volgens mij ook bij blauw (hoewel het daar iets minder sterk lijkt).

Euh... zou je een screenshot kunnen tonen, want hier snap ik geen bal van...

[EfBe]

Je gebruikt glColor3ub(), het klinkt alsof de driver die je gebruikt op linux niet goed werkt kennelijk... Maar als je een screenshot zou kunnen posten dan weten we waarover we praten.

Ook op windows geprobeerd, dit programma? (ik heb glut niet, alleen mn eigen lib, dus kan nu 1 2 3 niet testen)

[Verwijderd]

Maar als je een screenshot zou kunnen posten dan weten we waarover we praten.

Ik ben nu niet thuis, dus dat wordt helaas wat lastig. Goed, ik probeer wel kort te omschrijven wat het programma globaal doet.

1. Het leest een textfile met een lijst van RGB-waarden in, bijvoorbeeld:
7,0,0
15,0,0
23,0,0
31,0,0
.
.
255,0,0
0,7,0
0,15,0
.
.
0,255,0

2. Er wordt een vierkantje op het scherm geplaatst met RGB gelijk aan eerste regel uit textfile. Na 4 seconden verandert het vierkantje van kleur, nl RGB gelijk aan tweede regel uit textfile, etc.

Tegelijkertijd zal er een kleurmeter op het vierkant gericht zijn, welke voor ieder vierkantje de CIE-coordinaten zal meten (x,y,Y). Helaas heb ik nog geen beschikking over de te gebruiken kleurmeter, dus kan niet in CIE-termen gaan uitdrukken wat er nou precies gebeurt. Maar zo op het oog lijkt er dus al duidelijk iets niet goed te zijn.

Als de textfile zoals in bovenstaand voorbeeldje wordt gebruikt zou je eerst een reeks rode vlakjes en dan een reeks groene vlakjes moeten krijgen. Voor zover ik me herinner zie ik ongeveer het volgende (m.b.t. rode reeks):

A: (7,0,0) ... ~(63,0,0) : erg donker; je ziet nauwelijks een vierkant
B: ~(63,0,0) .. ~(151,0,0): de stimulus wordt steeds 'roder'
C: ~(151,0,0) .. (199,0,0): de stimulus begint wel heel erg 'licht' te worden
D: (207,0,0): de stimulus wordt plots weer donkderder
E: (215,0,0) ... (255,0,0): de stimulus wordt weer steeds 'roder', geloof ik

A lijtk me vrij normaal; alle kanonnen staan min of meer uit
B lijkt me ook vrij normaal
Wat C betreft: het LIJKT alsof de kleur steeds minder gesatureerd wordt (tot bijna op het witte af aan het eind); dit zou niet het geval moeten zijn, want om saturatie te regelen worden volgens mij ook de andere 2 kanonnen gebruikt (terwijl die beide 0 zouden moeten zijn)
D: er is duidelijk iets niet helemaal goed

En als ik bijv (263,0,0) als RGB geef dan krijg ik plotseling een donkergroene kleur. Ik vind dit zelf wat vreemd, want GB = 00; normaliter zou toch gelden R = 263 mod 256 = 7 ?!

Naja, als het echt niet lukt kan ik het altijd nog zonder openGL gaan doen. Hoewel het de bedoeling is dat de programma's/experimenten waarvoor we gecalibreerde projectoren nou juist nodig hebben wel openGL zullen gebruiken...

[.oisyn]

EfBe schreef op 24 maart 2004 @ 09:23:
Je gebruikt glColor3ub(), het klinkt alsof de driver die je gebruikt op linux niet goed werkt kennelijk... Maar als je een screenshot zou kunnen posten dan weten we waarover we praten.

Hij zei dat het met floats ook fout ging