LE post qui a tout demarré: fabriquer son colorimetre

[Georges G]

Salut Manu

Ben dis donc, tu arrives déjà à en faire des choses, avec un simple luxmètre

Pour la correction, je compte pour ma part utiliser l'égaliseur vidéo de l'appli Holo3D (ou plus simplement les réglages gamma par composantes). Mais dans ffdshow, je n'ai rien vu de tel (mais bon, puisqu'on peut y mettre des filtres de DScaler). Or, dans DScaler, il existe un filtre de gamma... Il est relativement facile de redévelopper à partir de ses sources un gamma par composantes, afin de le brancher dans ffdshow

A bientot
Georges

[Georges G]

Ajout: je viens de télécharger les sources de DScaler pour jeter un oeil au filtre Gamma... finalement, c'est pas simple du tout à faire, vu que ça travaille sur l'overlay, et que le format des octets est YUYV ou un truc comme ça, mais certainement pas RGB

A bientot
Georges

[MLill]

Bonjour à tous, en particulier à Georges qui m'a signalé ce sujet et un encouragement tout particulier à Manu

La problèmatique est très bien exposée (je trouve ) par Mark dans cet article :

http://www.milori.com/articles/color_measurement.asp

L'idée naturelle consiste à utiliser trois capteurs et trois filtres (un pour le rouge un pour le vert et un pour le bleu).

La solution est OK si l'on dispose de filtres parfaits (et parfaitement adaptés aux capteurs utilisés).
Si ce n'est pas le cas on peut envisager d'utiliser plus de trois capteurs (et plus de trois filtres).
Plus il y en a et plus on se rapproche d'un spectromètre.

...

Une fois le dispositif réalisé il faut le calibrer.
Et normalement le calibrage doit être fait avec le projecteur utilisé (ou un projecteur équivalent c'est à dire de même spectre).
Ce problème est réglé si on a accès (pas forcément longtenmps) a un outil de calibrage pro ou semi-pro.

...

Sans calibrage on peut valider la linéarité de la courbe (où ce qui revient au même le gamma sur les 3 composantes).
C'est à mon avis déjà un pas très important de franchi (avoir le même rendu des couleurs tout au long de l'échelle de gris).
Manu nous l'a montré ci-dessus.

Michel

[EPira]

Whouaaa, le grand maître des images sur ce thread
Merci pour les encouragements Michel et pour la doc de chez Milori effectivement c'est tres bien detaillé !

Georges, les versions recentes (mais pas forcement fonctionnelles ...) de ffdshow incluent le reglage de gamma separé pour chaque couleur RGB :



Je pense que cette application doit etre modifiable pour nos besoins, si j'ai le temps je jete un coup d'oeil aux sources.

Sinon plus ca va plus je pense qu'effectivement chercher a avoir une valeur "absolue" de colorimetrie n'est pas facilement realisable, alors que mesurer des valeurs relatives comme je l'ai fait et tres simple et efficient.

Du coup, je suis pas sur qu'une version tri-capteur soit necessaire, avec un simple capteur ont doit pouvoir optenir qque chose tres bon, le tout etant effectivement d'avoir un blanc de reference, par exemple en utilisant la methode proposée par Georges d'utilisation d'une ampoule 6500°K. Une fois ce blanc obtenu, il suffit de travailler sur les couleurs RGB les une apres les autres.

Pour la numerisation, je vais experimenter une solution a faible coup en utilisant un convertisseur tension frenquence (LM331) et j'injecterais le signal sur l'entree de la carte son ! Le convertisseur a une precision de 0.01% d'apres la spec, et mesurer une frequence ne devrait pas poser de pb a une application meme avec une carte son premier prix

Dans la spec du LM331 que j'ai sous le coude il y a meme deja ce genre de montage de proposé :



Manu.

[Georges G]

Salut Michel

Bienvenue sur ce fil ! Comme tu le vois, Manu a bien bossé !

Manu, en ce qui concerne ton idée de faire un système avec un unique capteur et un convertisseur tension/fréquence relié à la carte son, je t'avoue que je trouve ça assez inutile... On peut faire exactement la même chose avec un simple luxmètre, et certains peuvent déjà être reliés à un PC

De mon point de vue, un tri- ou quadri-stimulus vaut le coup, parce qu'il permet de façon rapide et efficace de régler les gammas par composantes et d'extrapoler des choses importante, notamment en ce qui concerne les noirs imparfaits des projecteurs numériques. Sinon, autant faire ça avec un luxmètre tout simple, un jeu de filtres et une calculatrice...

En tout cas, tu as pu démontrer que la cellule du luxmètre a de très bonnes perfs, et c'est déjà beaucoup !

Sinon, j'imagine que tu vas faire des tests avec les réglages gamma RVB de ffdshow ? Tiens nous au courant ! Pour ma part, ça m'arrange, je commençais déjà à cogiter à l'écriture d'un filtre gamma RVB pour DScaler

A bientot
Georges

[EPira]

Salut Michel

Bienvenue sur ce fil ! Comme tu le vois, Manu a bien bossé !

Manu, en ce qui concerne ton idée de faire un système avec un unique capteur et un convertisseur tension/fréquence relié à la carte son, je t'avoue que je trouve ça assez inutile... On peut faire exactement la même chose avec un simple luxmètre, et certains peuvent déjà être reliés à un PC

Heuuu oui, mais la je parle d'une solution imbattable a 15 euros

De mon point de vue, un tri- ou quadri-stimulus vaut le coup, parce qu'il permet de façon rapide et efficace de régler les gammas par composantes et d'extrapoler des choses importante, notamment en ce qui concerne les noirs imparfaits des projecteurs numériques.

Ben c'est exactement ce que tu vas faire avec un mono-capteur !?
pour moi le multi-capteur n'avait qu'un seul et unique interret, me donner la des valeurs absolues de "blanc", mais comme on a vu que ca necessitait des filtres complexe pour ce faire, autant partir sur une version + simple.

La difference entre un mono et un tri capteur pour la mesure du gamma se trouve uniquement dans le temps que ca prendre, avec un tri-capteur en une passe tu fais tout alors qu'avec un mono tu dois le faire en trois fois, si c'est automatisé ca ne change pas grand chose

Un tri-capteur bien etalloné pourrait effectivement dire par exemple que pour avoir un jaune ideal avec ton projo, il faut 100% de rouge, 100% de vert (normal) mais 5% de bleu, mais ca sert a quoi puisque (de base) tu ne peux regler la saturation des couleurs qu'independament les unes des autres, que ce soit dans les menus des projos ou dans les ordis. Si ca presente in interet, on pourrait faire une table de correspondance RGBout = F(RGBin), ca ne represente "que" 64Mo de data, et la tu aurais vraiment qque chose au poil au niveau couleur !!

Sinon, autant faire ça avec un luxmètre tout simple, un jeu de filtres et une calculatrice...

C'est exactement ce que je fais, mais pas besoin de filtre puisque tu travailles sur chaque couleur independament !

En tout cas, tu as pu démontrer que la cellule du luxmètre a de très bonnes perfs, et c'est déjà beaucoup !

Tout a fait, la linearité a l'air effectivement tres bonne et le capteur est encore largement sensible dans le bleu, ce qui n'etait pas forcement evident.

Sinon, j'imagine que tu vas faire des tests avec les réglages gamma RVB de ffdshow ? Tiens nous au courant ! Pour ma part, ça m'arrange, je commençais déjà à cogiter à l'écriture d'un filtre gamma RVB pour DScaler

Je vais essayer oui, mais deja je vais peaufiner ma methode de prise de mesure, et refaire une serie de mesure !

Manu.

[MLill]

Le capteur DIY a un avantage sur le luxmètre commercial.
Celui-ci est en effet toujours muni d'un filtre privilégiant le vert comme notre chère rétine.
On perd beaucoup de sensibilité si on lui colle devant un filtre bleu ou un filtre rouge.

Sinon plus ca va plus je pense qu'effectivement chercher a avoir une valeur "absolue" de colorimetrie n'est pas facilement realisable, alors que mesurer des valeurs relatives comme je l'ai fait et tres simple et efficient.

Tout à fait et l'on a moins besoin de valeurs absolues qu'on ne le pense.
En fait il suffit d'une mesure pour s'étalonner.

Michel

[Georges G]

Salut Michel

J'ignorais cette histoire de filtrage des luxmètres du commerce, et le problème de sensibilité qui en découle quand on veut filtrer Bon, je sens qu'il va falloir que je m'en fasse un en DIY... Manu, on peut avoir les plans et la nomenclature de ton engin ?

A bientot
Georges

[Georges G]

Pour Manu:

La photodiode BPW-21R est dispo chez selectronic à 6,80 euros... Est-ce qu'elle marcherait avec ton montage ? Ils n'ont pas de BPW 34... et j'ai une commande à faire très bientôt chez eux, autant faire groupir pour économiser le port

A bientot
Georges

[EPira]

Hello,
Oui, la bpw21r (a droite fig. 5) est tres bien et meme mieux que la bpw34 (a gauche fig. 7) car plus centrée sur le domaine visible :


Pour le montage, pour l'instant je suis sur celui de la fig. 125 de ce document



J'ai un aop mono tension lm358 avec en guise de R un potard de 1Mo qui me permet de regler le gain, plus une capa de 4.7nF en // sur ce potard (pre-filtrage) et en sortie de l'aop une resistance de 47K qui rempli une capa de 4.7uF (filtrage), bref des composants que j'avais sous la main

Le filtrage est necessaire etant donné que dans mon cas l'ecran (IIYAMA ou barco) est balayé de ligne toutes les 60khz et rafraichi toutes les 75hz, et a l'oscillo sans filtrage je voyais tres bien le faisceau passer devant le capteur quand il etait collé a l'ecran

Je pense essayer les autres montages (fig. 127), car en faible luminosité le montage actuel necessite un gain tres important (le potard 1Mo est a fond).

Manu.

[EPira]

Yessssss !

http://www.ati.com/developer/sdk/RADEONSDK/Html/Tutorials/RADEONGamma.html

...

Gamma Table APIs

Windows® - SetDeviceGammaRamp()

In Win32, there are two entrypoints for setting the gamma table. These entrypoints give the application control over how much (if any) gamma correction is performed. Special effects like screen flashes can even be done inexpensively by using the gamma table to briefly invert frame buffer values during scan out.

The most generic API for setting the gamma table is the Win32 entrypoint SetDeviceGammaRamp(). Since this is just part of Win32, any application can set it, though it's really only appropriate for fullscreen applications to take control of the gamma table, as there is currently no notion of per-window gamma in the OS. This entrypoint is what OpenGL® applications typically use to set their gamma ramps. The function prototype looks like:

BOOL WINAPI SetDeviceGammaRamp( HDC hDC, LPVOID lpRamp );
where
hDC is a handle to the device context
lpRamp is a pointer to a buffer containing the gamma ramp to be set. The gamma ramp is specified in three consecutive arrays (for r, g and b) of 256 WORDs each, which contain the mapping between RGB values in the frame buffer and DAC values. The RGB values must be stored in the most significant bits of each WORD to increase DAC independence.
The function returns TRUE on success and FALSE on failure.

...

Je vais essayer ca de suite !!

Manu.

[EPira]

Et ca marche !
Je viens de faire un test en visual basic en utilisant l'exemple ce cette page :
http://www.metz-furniere.de/jens/vbsource.html

Code: Tout sélectionner

Wie kann ich die Helligkeit des Monitors per Programmcode verändern?

Die Helligkeit kann mit ein paar Zeilen geändert werden:
In den Deklarationen der Form:

Private Ramp1(0 To 255, 0 To 2) As Integer
Private Ramp2(0 To 255, 0 To 2) As Integer
Private Declare Function GetDeviceGammaRamp Lib "gdi32" (ByVal hdc As Long, lpv As Any) As Long
Private Declare Function SetDeviceGammaRamp Lib "gdi32" (ByVal hdc As Long, lpv As Any) As Long
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long)

Public Function Int2Lng(IntVal As Integer) As Long
   CopyMemory Int2Lng, IntVal, 2
End Function
Public Function Lng2Int(Value As Long) As Integer
   CopyMemory Lng2Int, Value, 2
End Function
Private Sub Form_Unload(Cancel As Integer)
   SetDeviceGammaRamp Me.hdc, Ramp1(0, 0)  'Beim Beenden wieder normale Helligkeit
End Sub
Dort, wo es dunkel werden soll:

Dim iCtr       As Integer
Dim lVal       As Long
GetDeviceGammaRamp Me.hdc, Ramp1(0, 0)
For iCtr = 0 To 255
  lVal = Int2Lng(Ramp1(iCtr, 0))
  Ramp2(iCtr, 0) = Lng2Int(Int2Lng(Ramp1(iCtr, 0)) / 2)
  Ramp2(iCtr, 1) = Lng2Int(Int2Lng(Ramp1(iCtr, 1)) / 2)
  Ramp2(iCtr, 2) = Lng2Int(Int2Lng(Ramp1(iCtr, 2)) / 2)
Next iCtr
SetDeviceGammaRamp Me.hdc, Ramp2(0, 0)
   
Sie können auch die Farbe verändern wenn sie die entsprechenden Zeilen auskommentieren.


On a donc un moyen de regler exactement les valeurs que l'on souhaite en sortie de DAC ce qui est nickel, il n'y a plus qu'a faire les mesures, calculer les corrections et rentrer les parametres et corriger l'image !!

Ca n'affecte pas l'overlay, mais ca c'est pas un probleme (si ca se trouve il y a la meme fonction pour l'overlay ...)

Manu.

[EPira]

Bon, il semblerait que l'on ne puisse pas faire ce que l'on veut du SetDeviceGammaRamp, qu'il y aurait un controle sur les données http://www.monkeybreadsoftware.de/realbasic/listarchive/thread_25012003_1.shtml

SetDeviceGammaRamp doesn't allow all gamma ramps. It checks the gamma
ramp; if it is too complex, such as the red flash when the player is
shot in Quake, it rejects it.
SetDeviceGammaRamp will not currently make use of a gamma calibrator.
This may change in future versions of Image Color Management (ICM), but
for Windows 2000, only the DirectDraw API supports the gamma
calibrators.
The existing gamma entry points is already used by GetDeviceGammaRamp
and SetDeviceGammaRamp. Therefore, the display driver doesn't need to do
anything special to support this new interface, as long as it already
supports the Win32 Get/SetDeviceGammaRamp functions.
In addition to getting and setting gamma ramps, the new DirectDraw
interface allows the new gamma ramp to be calibrated-if a gamma
calibrator is installed. The mechanism that DirectDraw uses to register
and communicate with the gamma calibrator is an interim mechanism that
will be changed in future releases.
DirectDraw looks for an installed software calibrator and passes the
gamma value to the software calibrator; the software calibrator in turn
adjusts the gamma ramp according to the measured response of the
monitor. The calibrator passes the gamma ramp back to DirectDraw, which
passes it to the SetDeviceGammaRamp device driver interface (DDI). The
result is that the game looks as intended.
For DirectDraw to use the gamma calibrator, the calibrator must register
itself with DirectDraw using a registry key; DirectDraw will call it if
the application wants the gamma ramp to be calibrated.
In the future, both the method by which DirectDraw communicates with the
gamma calibrator, through the DDI, and the method gamma calibrators use
to register themselves in the registry will change. But every part of
the DirectDraw API is permanent.
ICM is the color management system in Windows; all system-level color
management should be handled by ICM. For this reason, downloadable gamma
ramp support will be rolled into ICM in the future, making current
solutions for gamma calibrators obsolete. Until such time, we have
provided a method by which applications can take advantage of the
installed base of software calibrators and graphics adapters that
support downloadable gamma ramps.


bon, et les profils de couleur de windows (*.icm ou *.icc), qq'un sait comment les creer ?

Manu

[Georges G]

Salut Manu

Concernant le montage, je vais donc attendre pour que tu me conseilles l'un ou l'autre montage, et les bonnes valeurs de composants... c'est que je n'y connais vraiment rien en électronique

Pour la table de gamma, je doute qu'elle agisse sur l'overlay. De ce côté là, je pense qu'on n'est pas plus avancés... sauf si tu comptes utiliser VRM9

Si j'ai bien compris, tu abandonnes l'idée de concevoir un tri-stimulus relié au PC ? Je trouve ça dommage, parce que ça interdit d'écrire un soft qui automatise le réglage...

A bientot
Georges

[EPira]

Salut Manu

Concernant le montage, je vais donc attendre pour que tu me conseilles l'un ou l'autre montage, et les bonnes valeurs de composants... c'est que je n'y connais vraiment rien en électronique

Comme tu veux, mais de toute facon il faut les memes composants dans un cas comme dans l'autre

Pour la table de gamma, je doute qu'elle agisse sur l'overlay. De ce côté là, je pense qu'on n'est pas plus avancés... sauf si tu comptes utiliser VRM9

Oui, comme je l'ai indiqué ca ne concerne que l'affichage normal, mais je suppose qu'il doit exister la meme chose pour l'overlay. et si le reglage est utilisable uniquement en affichage normal, aucun pb pour l'utiliser en lieu et place de l'overlay, l'overlay (sauf erreur de ma part) n'etant qu'un mode "acceleré" d'affichage.

Si j'ai bien compris, tu abandonnes l'idée de concevoir un tri-stimulus relié au PC ? Je trouve ça dommage, parce que ça interdit d'écrire un soft qui automatise le réglage...

Pour l'instant je n'en vois pas l'interet, mais je vais faire une version mono capteur relié au pc et il faudra bien evidemment un logiciel pour automatiser les reglages (?!)

Manu