Il me faut un coup de pouce, cela fait plus de 20 fois que j'essaie de comprendre et rien ni fait, cela concerne la convertion RGB -> CRY. Atari a écrit ceci dessus, mais avant de vous donner en pature ce qu'a écrit Atari, je vais vite faire une rapide explication du format Cry au cas ou :



Le CRY est composé de trois parties :



- C : Cyan codé sur 4 bits

- R : Rouge codé sur 4 bits aussi

- Y : intensité codé sur 8 bits, cela correspondrait a l'éclairage

du point en gros, plus il est elevée plus la couleur est claire.



Et voici ce qu'écrit Atari pour faire la convertion :



The best technique is to calculate the intensity value, which is the largest red, green and blue; and from this the ideal ROM entry for that colour, by scaling the RGB values by 255/intensity. This can be matched to the actual ROM tables to find the nearest match. A quick way of doing this is by a lookup table. It is not necessary for this to have 2^24 entries, it turns out that taking the top 5 bits of each red, green and blue values (rounding where appropriate) and using a 32768 element lookup table is adequate.



Physical implementation :



The eight-bit colour value is used to index a look-up table of modifier values for each red, green and blue; which is multiplied by the intensity value to give the output level for each drive to display. The lookup tables ares :



Ensuite viennent 3 tables, une pour chaque composante (R, V et B)

Constitué de 256 valeurs (16 colonnes par 16 lignes) valeur codé

sur un octet (val max 255).



Si on peut m'aidé a comprendre ce charabia, en règle général les docs techniques anglaises me dérangent pas, mais la je suis a coté de la plaque et correctement !!



GT Turbo :wacko:

Mouais... pas l'air terrible comme explication, j'en perd mon latin. J'ai récup la doc, je regarde ça ce soir, mais franchement la conversion a l'air d'être une grosse daube.

J'ai pas trouvé d'infos concernant le cry, mais pas contre, je viens de trouver par hasard des infos sur la vidéo qui pourrait être intéressantes.

Pour la vidéo : http://www.mulle-kybernetik.com/jagdox/video.html

Le sommaire de la doc : http://www.mulle-kybernetik.com/jagdox/dox.html



C'est peut être déjà connu mais bon autant se le garder de coté.

Je peux expliquer sans probleme comment fonctionne la convertion RGB->CRY et inversement..

(je l'ai utilisé pour le traitement video pour le robot : avec 60 frames / secondes en 320*240)



en fait, la vrai formule de convertion est si compliqué qu'il est préférable d'utiliser une table de convertion.

Pour cela, il y a 2 tables possibles :

-une petite table de 32Ko mais il faut faire un peu de calcul

-une table de 16Mo donc sans calcul mais sa prend de la place



la méthode la plus rentable est sans doute la premiere (sauf si l'on a suffisament de RAM)

pour la convertion RGB->CRY :



il suffit de faire le calcul suivant :

1) calcul de Y:

Y = max(R,G,B)



2) calcul de la position de la couleur dans le tableau 3D :

si Y est différent de 0 :

XX = ((r * 255) / y)>>3;

YY = ((g * 255) / y)>>3;

ZZ = ((b * 255) / y)>>3;

sinon

XX = 0;

YY = 0;

ZZ = 0;



3) lire la valeur CR dans le tableau :

CR = tab[XX][YY][ZZ]



le tableau de convertion est dans l'ordre (en code C pourrit mais comprehensible ;)):

for (i = 0; i <= 0x1F; i++)

{

for (j = 0; j <= 0x1F; j++)

{

for (k = 0; k <= 0x1F; k++)

{

tab[i][j][k] = fgetc(f_rgb2cry);

}

}

}



(Comment on fait pour joindre un fichier ?)



pour convertir de CRY a RGB, il faut :

les 3 tableaux qui sont dans la documentation de la JAG



puis faire le calcul suivant:

(C,R, et Y corespondent aux éléments du pixels CRY)

rouge = (tab_rouge[C][R]*Y)/255

vert = (tab_vert[C][R]*Y)/255

bleu = (tab_bleu[C][R]*Y)/255

Génial !!!



C'est quoi ton symbole ">>" dans







Pour RaZ :



Il y aurait un bug étrange : le "i" entre crochet est pris pour la commande "italique", comment faire pour avoir un "vrai i crochet" ? Je tente un essai : [i] [i] [i]

le symbole >> correspond a faire une rotation de bit vers la droite

donc X >> 3 c'est : faire une 3 rotations de bit vers la droite pour X (donc X/2^3)

Peut être avec un espace (au moins) : [i ]

Et je suppose que c'est normal que je n'ai rien compris à la formule de conversion... :unsure:



Pour les fichiers, il faut que j'active les PFS/EFP (Espace de Fichiers Personnel) mais je me tate encore sur l'espace que ça pourrait prendre.

Vu l'heure à laquelle tu t'es intéressé à la formule c'est normal, puis même à une heure normale elle est pas compréhensible cette formule... pas envie d'y réfléchir dessus... d'autres formules à fouetter...

Merci SCPCD !! Parce que hier soir j'ai essayé comme un ane des trucs au hasard.







Tant mieux pour du code C compréhensible, par contre je suis un petit peu perdu, la fonction fgetc(), la je comprends pas (Je sui une m.... en c, faut le savoir !) renvoie quoi comme valeur, comment, etc...



le >>> je comprens cela correspond a un bon vieux lsr.w #3 (68000 powa !)



GT Heureux :yes:

en fait, fgetc c'est la fonction C qui permet de lire un fichier.

elle retourne l'octet pointer par le pointeur de fichier et fait pointer le pointeur (:wacko:) du fichier sur l'octet suivant. :blink:



En gros, la fonction C que j'ai mis sert a lire le fichier des valeurs de convertion et de remplir le tableau tab[i ][j][k] dans un certain ordre.

[pfs]5-rgb2cry.zip[/pfs]

Nickel !! J'ai le fichier et vais allé modifié mon code qui marche pas en appliquant tout cela !!



YES !!! GT Heureux !! :yes:

Histoire d'embéter mon monde, il n'y a personne qui puisse nous faire un petit programme pour PC qui utilise la table de 16Mo ?

Un bête convertisseur BMP->CRY, 16Mo ne représente plus rien dans le monde PC, c'est plus que jouable et ça éviterais les approximations des calculs.

Templeton pourrait finir par vraiment tirer la gueule si on lui pourrit tout ses graphs ;)

ben si quelqu'un a la formule je veux bien en faire un en ligne de commande.

La technique marche au poil, je peux convertir two fingers in the nose !!



Merci SCPCD !!



Ca j'aime une question technique et une personne qui peut te donné une réponse propre et net et qui marche !!!







GT Trop heureux !! :yes:

De rien...



C'est grâce à CTS que j'ai moi même réussi ;)



Sinon, j'ai fini par retrouver les formules exactes de convertion RGB->CRY et donc aussi de CRY->RGB. C'était pas évident à retrouver : c'est plusieurs changements de base mais le calcul en lui même est en fait relativement simple.

Mais elles ne sont encore que sur papier.



SCPCD.

Petite entorse :



Tu sais ou il est Cts en passant ? Personne n'a plus de nouvelle et il serait le bienvenue ici.





GT ;)

Je crois qu'il traine sur des forums linux sous les pseudos cts ou ctsnlc ...

Pas de nouvelles ... :(

J'ai mis a jour la doc pdf que j'ai commencé en fevrier

J'ai donc rajouté la formule brut de la convertion RGB2CRY et CRY2RGB.



http://scpcd.free.fr/downloads/fichiers/JETRM_F.pdf



n'hésitez surtout pas a dire ce qui ne va pas...

et si vous voulez rajouter des choses pas de problemes :yes: c'est fait pour.

Salut,

j'ai écrit vite fait en OCaml un outil de conversion d'images pour la Jaguar.

Ceux qui peuvent installer OCaml et la librairie camlimages sont concernés (en gros, les PCistes linuxiens ou à la limite les windowsiens avec cygwin), pour les autres, il y a sur Atari l'excellent Ellipse de GT Turbo.
Ca convertit les fichiers BMP/PNG/JPEG/TIFF/GIF/? vers RGB16 ou CRY16 (en ascii ou binaire).
Les sources OCaml (GPL) sont téléchargeables à l'URL http://removers.free.fr/softs/download.php.
La formule exacte de SCPCD est utilisée pour la conversion en CRY16.

Seb

Pas grave, même en les pourrissant... mes graphs restent magnifiques !


....fffff.... merde ma cheville !!!!!! ....FFFFFFF..... PAF !!!!! AAAAAAAAAHHHH!!!!!

>Pas grave, même en les pourrissant... mes graphs restent magnifiques !
Oui.
Mais Raz a raison, tu tires la gueule (à raison) quand même

une vraie bombe, plus rapide que GT... je propose d'ailleurs qu'il faut soit renommer GT en Lada, soit renommer SebRmv en NoX...


En compilant avec les librairies graphiques sous gcc ça ne fonctionne pas ? avec la libjpeg, la libtiff, libpng, libpng, libtga... je ne m'y suis pas lancé, mais ça devrait fonctionner, non ?

hop là, bon, je viens de voir la réponse d'Azrael...
la librairie camlimages utilise effectivement libjpeg, libtiff, libpng, ...
à noter que je peux aussi fournir (à la demande) un binaire qui marchera (je l'espère) sous linux (mandriva 2006 mais peut être les autres aussi)
je peux aussi compiler une version "bytecode" (plus lente) qui marchera probablement sous cygwin aussi

et puis, en fait, je voulais surtout dire que j'avais fait un update qui permet maintenant de traiter les modes palette

Seb