none
PixelFormats BGR101010 RRS feed

  • Question

  • Bonjour,

    J'envisageais de traiter des images avec 12 bits par canal mais, puisqu'un format sur 10 bits (bgr101010) est proposé, je compte d'abord l'essayer. Malheureusement, si le format existe, la documentation est absente. Une recherche sur l'internet ne produit rien de plus que ce qu'a écrit MS : " ". La question est donc comment un pixel codé sur 8 bits (typiquement BGR32, qui devrait d'ailleurs être nommé RGB32 pour respecter l'ordre de lecture) est-il traduit en 10 bits par FormatConvertedBitmap ? A titre d'exemple, voici ce que je relève sur un pixel quelconque avec un conversion BGR32 :

    1111-1111-1100-0011-0101-0100-0011-1110 (successivement A, R, G, B) ;

    et voici, sauf erreur de copie du bitmap dans le tableau (bien qu'a priori le stride soit identique), le même pixel en BGR101010 :

    1110-1000-1110-0101-0100-0100-1111-1000.

    Je ne vois là aucune conversion évidente. L'un de vous connaît-il la réponse ?

    mardi 23 septembre 2014 18:53

Réponses

  • Voilà ce qui me paraît la réponse exacte : BGR101010 ne décale pas chaque composante d'un BGR32 de 2 bits à gauche mais la multiplie par 1023/255, ce qui a l'avantage de conserver la valeur normée à 1 et l'inconvénient d'ajouter un calcul et un arrondi.

    Cordialement.

    vendredi 26 septembre 2014 17:52

Toutes les réponses

  • Bonjour,

    J'envisageais de traiter des images avec 12 bits par canal mais, puisqu'un format sur 10 bits (bgr101010) est proposé, je compte d'abord l'essayer.
    Que voulez vous faire exactement ? L'afficher dans une fenêtre WPF ?

    Avez-vous essayé de regarder ce projet open source : http://imagemagick.codeplex.com/ il permet de manipuler différents format d'images....

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance - P.O.S Informatique
    Blog : http://gilles.tourreau.fr - Suivez-moi sur Twitter
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCSA : SQL Server 2012
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0 / TFS 2010 / Windows Azure

    mardi 23 septembre 2014 22:42
    Modérateur
  • Bonjour Gilles,

    L'affichage n'est pas un problème. L'application à laquelle je travaille rassemblera plusieurs algorithmes de traitement d'image que j'ai mis au point à l'origine avec GDI+ (par simplification, je ne connaissais rien du xaml). Je suis passé à WPF pour créer une interface propre - tous les contrôles sont modifiés - et, les méthodes étant plus efficaces, j'en profite pour augmenter la précision de calcul. Naturellement, l'affichage et l'enregistrement de fichier restent sur 8 bits par primaire. Soit je mets la main sur la manière dont les pixels sont codés en BGR101010, qui permettrait de garder les bitmaps des calculs précédents sans conversion, soit je crée mon propre code sur 12 bits et allonge un peu le programme. Était-ce le sens de vos questions ?

    mercredi 24 septembre 2014 16:42
  • Bonjour,

    Il me semble qu'il est préférable d'utiliser un encodage sur 8 bits (un octets) qui sont beaucoup plus simple à manipuler en C#... Si vous codez votre propre code sur 12 bits, il faudra utiliser un short (ou ushort) qui tient sur 16 bits... De plus (il me semble) que le codage BGR101010 nécessite l'utilisation de masque ce qui n'est pas très optimal pour une utilisation avec C#...

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance - P.O.S Informatique
    Blog : http://gilles.tourreau.fr - Suivez-moi sur Twitter
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCSA : SQL Server 2012
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0 / TFS 2010 / Windows Azure

    mercredi 24 septembre 2014 22:30
    Modérateur
  • Lightroom travaille sur 4x16 bits, un raffinement superflu à mon sens, mais calculer sur 12 bits, 10 à la rigueur, limite les erreurs d'arrondi, élément important lorsqu'on enchaîne les corrections et, vraiment, ce n'est pas une contrainte technique. Il ne me semble pas que le BGR101010 utilise un masque mais en sait-on plus sur ce codage ?

    Cordialement.

    Après quelques mesures faites sur des images artificielles, il semblerait qu'un pixel codé sur 8 bits par primaire noté RVB du poids fort au poids faible soit transformé en 11-R(10 bits)-V(10 bits)-B(10 bits) où chaque composante est décalée à gauche de 2 bits. J'écris semblerait parce que les bits de décalage ne valent pas systématiquement 00, il arrive même que le bit suivant ne soit pas toujours identique au premier bit de la primaire. Voici un exemple.

    Un pixel donné vaut FF 00 74 74 en BGR32. Selon le principe précédent, il devrait valoir C0 07 41 D0 après décalages or je relève C0 07 45 D1. Je ne trouve pas d'explication à ces différences à moins, peut-être, que le pixel mesuré en second ne soit pas le pixel initial ? Mais comment le pixel de rang n dans un tableau unidimensionnel d'une image BGR32 n'aurait-il pas le même rang dans le tableau tiré de la même image convertie en BGR101010 alors que les deux sont codés sur 4 octets ?

    Denier ajout. Cette supposition sur le rang ne tient pas, elle n'explique pas que les bits de décalage puissent valoir 01 ou 11.


    • Modifié Tirfon vendredi 26 septembre 2014 16:21
    jeudi 25 septembre 2014 16:42
  • Voilà ce qui me paraît la réponse exacte : BGR101010 ne décale pas chaque composante d'un BGR32 de 2 bits à gauche mais la multiplie par 1023/255, ce qui a l'avantage de conserver la valeur normée à 1 et l'inconvénient d'ajouter un calcul et un arrondi.

    Cordialement.

    vendredi 26 septembre 2014 17:52
  • Quelqu'un peut-il fermer cette question ? Je ne vais tout de même pas valider le fait que j'en ai trouvé la réponse depuis un mois.
    mercredi 29 octobre 2014 21:00
  • Bonjour,

    Je marque votre message comme réponse.

    Ce n'est pas un problème si nous validons votre réponse un mois plus-tard... Le but est de marquer les threads où il y a une réponse afin d'aider les personnes qui viendrons plus-tard en leur indiquant "voilà la réponse et ca marche !".

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance - P.O.S Informatique
    Blog : http://gilles.tourreau.fr - Suivez-moi sur Twitter
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCSA : SQL Server 2012
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0 / TFS 2010 / Windows Azure

    vendredi 31 octobre 2014 01:02
    Modérateur