Apres GIF, le JPEG

Posté par  . Modéré par Yann Hirou.
Étiquettes :
0
19
juil.
2002
Justice
Après l'affaire des brevets sur le format d'image gif, c'est au tour du format JPEG ! En effet, Forgent Networks, en rachetant Labs en 1997, a recupéré le brevet 4,698,672 qui couvre la compression jpeg.
NdM: Ils comptent faire payer les softs utilisant JPEG. Apparemment Sony serait déjà passé à la caisse.

Aller plus loin

  • # Les alternatives ?

    Posté par  . Évalué à 10.

    La news a déjà circuler il y a quelques jours sur slashdot. Y'a des trucs interresants qui ont été dis dessus. Il y a surtout dans le forum un modèle de lettre a envoyer a la société, il dis a peu près ça :
    message a envoyer a tous les employés de Forgent :
    Veuillez trouver ci joint ma collection de photo porno. Je vous les renvoi car j'ai utilisé le brevet JPEG de votre société par inadvertance. Je vous envoie le reste prochainement ....
    http://slashdot.org/article.pl?sid=02/07/18/157217&mode=thread&(...)

    Plus sérieusement, il y a aussi un projet hebergé par sourceforge qui se veut être une alternative libre a tous ses formats.
    http://djvu.sourceforge.net/(...)
    Apparement ils annoncent des compression plus importantes que le jpg. Par contre je ne sais pas si le rendu est bon. Est ce que quelqu'un à testé??
    • [^] # Re: Les alternatives ?

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Ben sinon, il y a le PNG qui est recommandé par le GNU dans la page expliquant le GIF (http://www.gnu.org/philosophy/gif.fr.html(...) ) avec un petit lien sur le site du PNG (http://www.libpng.org/pub/png/index.html(...) ).
      Par contre, la compression du PNG n'est pas extraordinaire mais je ne crois pas que l'algo soit destructif (d'ailleurs, j'en suis presque sûr).
      • [^] # Re: Les alternatives ?

        Posté par  . Évalué à 10.

        Bonjour,

        Après OpenGL, le format jpeg...

        Peut-être serait-il temps de faire le point sur les formats "à risque ?"

        Quid des formats audio ?

        Pour finir, au sujet du format png, et pour "rassurer" un peu (recopié sur le lien "burngifs")

        Q: Apple has a patent on PNG too, right?

        R: Wrong.
        "PNG alpha is identical to the version described in Porter and Duff's 1984 SIGGRAPH paper, which precedes Apple's filing by 8 years."
        -- Greg Roelofs, PNG Group

        Apple, encore...
      • [^] # Re: Les alternatives ?

        Posté par  . Évalué à 10.

      • [^] # Re: Les alternatives ?

        Posté par  . Évalué à 10.

        Le PNG n'est PAS une alternative au JPEG, il est assez mal adapte pour les photos.

        Par contre, pour djvu, ca a effectivement l'air interessant. Bon, j'ai teste rapidos (et ici, desole, mais trouve qu'un plugin commercial, djvulibre ne tourne que sous nunux, pas de nunux au labo, bouh honte a moi je sais), et j'ai trouve surtout, en exemple, des documents ecrits, scannes, etc., et il est effectivement presente comme tel. Donc la question est : est-ce que ca marche aussi bien aussi sur les photos, pour pouvoir etre un vrai format de remplacement au jpeg ?
        • [^] # Re: Les alternatives ?

          Posté par  . Évalué à 7.

          Le PNG n'est PAS une alternative au JPEG, il est assez mal adapte pour les photos.

          Une simple question: pourquoi est-il mal adapté?
          • [^] # Re: Les alternatives ?

            Posté par  . Évalué à -10.

            paske le tx de compression est pas tres important pour des grosses images.
            • [^] # Re: Les alternatives ?

              Posté par  . Évalué à 10.

              Pas du tout.

              Le PNG est un format qui indexe les couleurs. C'est donc peu adapté pour les photos qui en demande beaucoup, c'est en revanche très adapté pour les diagrammes et les dessin. Le jpeg lui garde les couleurs mais detruit un peu les formes. Pour un schéma c'est nul (trait qui bave) mais pour une photo c'est très bien.

              PNG est une alternative à GIF, mais *pas* à JPEG.
              • [^] # Re: Les alternatives ?

                Posté par  . Évalué à 7.

                Le PNG peut indexer les couleurs, mais il peut aussi travailler en 24 bits.
              • [^] # Re: Les alternatives ?

                Posté par  . Évalué à 10.

                *Si mes souvenirs sont bons* le JPEG encode les images en diagonale et par carré de 8x8 pixels, ce qui peut nuire aux images contenant beaucoup horizontales et de verticales pures (comme les diagrammes). Deplus il n'encode pas l'intensité des points, mais de variations d'intensité (des DeltaX plutot que des X) et il préfère les petites variations (d'où l'apparition de flou dans les zones à fort contraste). D'ailleurs en compressant un image avec le taux de perte maximal, on obtient un splendide monochrome de la couleur moyenne!
            • [^] # Re: Les alternatives ?

              Posté par  (site web personnel, Mastodon) . Évalué à 10.

              Le taux de compression n'est pas important car contrairement au JPEG, il n'est pas destructif (j'ai eu la confirmation). De là à dire que ce n'est pas adapté, cela dépend. Pour regarder une image comme ça en passant (qui a dit de fesses ?), le JPEG s'est sympa mais lorsque tu désires voir toutes les teintes, les contrastes... c'est foutu : en zoomant, il y a des gros patés, la résolution en ayant pris un coup à la compression.
      • [^] # Re: Les alternatives ?

        Posté par  . Évalué à 10.

        La compression varie énormément selon les conditions, mais en choisissant les bonnes propriétés de sauvegarde, elle est vraiment bonne.

        La compression n'est pas destructive et le PNG peut avoir un alpha-channel, permettant des effets bien supérieur aux gifs. Il existe en plus des applications pour optimiser la taille du fichier, style pngcrush (http://pmt.sourceforge.net/pngcrush/(...))
    • [^] # Re: Les alternatives ?

      Posté par  (site web personnel) . Évalué à 10.

      Ce format a l'air attrayant, en effet, à tester...


      Comme dans beaucoups d'autres cas qui se sont présentés au monde libre, il convient de se battre sur les 2 fronts dans ce cas aussi :

      1. Se battre positivement en créant de BONS formats dont ont soit sur qu'ils seront toujours libres (bz2 par exemple)

      2. Se battre négativement en luttant contre l'extension des brevets logiciels, notemment à l'Europe...
    • [^] # Re: Les alternatives ?

      Posté par  . Évalué à 10.

      Il y a la "compression par ondelettes"
      C'est mieux que le jpg mais je suis sûr qu'il y a des brevets.
      • [^] # Re: Les alternatives ?

        Posté par  . Évalué à 1.

        oui, les ondelettes (wavelets), il y a une implementation des ces algo : jpeg2000.

        mais ca n'a pas encore le succes merité.
    • [^] # Re: Les alternatives ?

      Posté par  (site web personnel) . Évalué à -1.

      Vu sur leur site:


      DjVu can be seen as nicely complementing PNG and MNG (which, unlike DjVu are lossless formats) in the areas of document image compression and lossy photo compression.


      C'est marrant parce qu'il m'a semblé que le site est en GIF... l'hopital qui se fout de la charité?
      • [^] # Re: Les alternatives ?

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        C'est marrant parce qu'il m'a semblé que le site est en GIF... l'hopital qui se fout de la charité?

        Si ils avaient fait les images de leur site au format djvu, personnes ne pourraient visionner correctement leur site vu que pratiquement personne n'a le plugin.

        Pour diffuser une information au pus grand nombre de personne, mieux vaut diffuser cette information de manière à ce qu'elle soit lisible par tout le monde.

        Bon, il est vrai qu'ils auraient peut etre du au moins utilise le PNG.. Mais tout les navigateurs ne le supportent pas ( vieilles versions ...)
        • [^] # Re: Les alternatives ?

          Posté par  . Évalué à 10.

          C'est justement ce qu'il voulait dire, car ils disent que PNG est un bon complément, mais sur leur site ils ne l'utilisent pas. Faites ce que je dis, ne faites pas ce que je fais
    • [^] # Re: Les alternatives ?

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Du coup, on se prendrait presque à rêver du JPEG2000 ;-)
    • [^] # Re: Les alternatives ?

      Posté par  . Évalué à 4.

      Si j'ai bien compris le FORMAT jpeg est basé sur une catégorie d'ALGORITHMEs de compression nommé JFIF. Qu'est qui m'empêche de faire un nouveau format utilisant JFIF? JFIF est breveté?

      Vu sur http://www.w3.org/Graphics/JPEG/(...)
      "Although the "baseline" variety of JPEG is believed patent-free, there are many patents associated with some optional features of JPEG, namely arithmetic coding and hierarchical storage. For this reason, these optional features are never used on the Web."
  • # libgd et autre

    Posté par  . Évalué à 10.

    et donc si cette affaire abouti, les librairies comme GD vont retirer le JPEG et v'la qu'il faut refaire toutes nos applications ...........


    bouh

    :-\
  • # ====> Moment correcteur orthographique <====

    Posté par  . Évalué à 10.

    c'est au tours du format
    c'est au tour du format

    a recuperé
    a recupé

    Ils compte faire payer les softs utilisant JPEG. apparement Sony serait déjà passé à la caisse.
    Ils comptent faire payer les softs utilisant JPEG. Apparemment Sony serait déjà passé à la caisse.

    Bon, pour ne pas faire que taquiner l'auteur de la news et le modérateur (qui ont dû sécher ensemble les cours de français:-)) il me semble que ça ne concerne que la partie transmission d'images en jpeg.
    Je me demande comment ils peuvent justifier ça ...
    A la limite, ils peuvent réclamer sur la compression d'images brutes qui sont transmises d'un appareil photo vers l'ordinateur qui les reçoit. Mais pas sur les navigateurs, où les images sont simplement transférées comme n'importe quelle donnée binaire entre le serveur http et le client.
    Quelqu'un a des précisions ?

    Il faut que je me relise bien, sinon ils ne me louperont pas (et ils auraient bien raison :-)).
    • [^] # Re: ====> Moment correcteur orthographique <====

      Posté par  . Évalué à 7.

      >il me semble que ça ne concerne que la partie
      >transmission d'images en jpeg.

      Ah ? Il me semblait avoir lu ca :

      >Forgent has the sole and exclusive right to use
      >and license all the claims under the '672
      >patent that implement JPEG in all "fields of use"
      >except in the satellite broadcast
      >business. Forgent's "fields of use" for licensing
      >opportunities include digital cameras,
      >digital still image devices, personal digital
      >assistants (PDA's), cellular telephones
      >that download images, browsers, digital camcorders
      >with a still image function, scanners
      >and other devices used to compress, store,
      >manipulate, print or transmit digital images.

      ...ce qui me semble couvrir toutes les utilisations possibles du jpeg (sauf diffusion par satellite... la faut m'expliquer les subtiles distinctions...)
      • [^] # Re: ====> Moment correcteur orthographique <====

        Posté par  . Évalué à 10.

        L'article du lien de The Register commence ainsi :
        "A video conferencing company based in Austin, Texas says it's going to pursue royalties on the transmission of JPEG images."

        Un peu plus loin ils parlent également de :
        "is seeking a deal wherever JPEGs are transmitted, with the exception of satellite broadcasting."

        Enfin, je lis aussi :
        "So the IP claim extends to any client device which receives a JPEG image."

        C'est pour toutes ces raisons que je me demande si on n'interprète pas un peu hâtivement la news ...
        Si je me permets de corriger les fautes de français des autres, je suis loin d'être aussi bon en british, alors si je fais une erreur de traduction, n'hésitez pas à frapper fort :-)
        • [^] # Re: ====> Moment correcteur orthographique <====

          Posté par  . Évalué à 8.

          Tout à fait d'accord avec toi. J'ai lu une bonne partie du brevet en question (qui est disponible à l'adresse http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITO(...) si cela vous intéresse) et, dans ce que j'ai lu, ils n'y parlent que de transmission d'images. Même, il y est indiqué que l'algorithme de compression se base sur des différences entre images successives et est prévu pour de la compression vidéo. Donc, il me semble que ce brevet devrait plus inquiéter l'algorithme MPEG que le JPEG. Toutefois, le communiqué de presse de Forgent (disponible ici : http://www.corporate-ir.net/ireye/ir_site.zhtml?ticker=forg&scr(...) ) cible bel et bien l'algorithme JPEG. Je trouve donc la situation plutôt bizarre.

          À noter également, ce brevet à été attribué en 1986 déjà, toutefois Forgent n'a jamais cherché à faire valoir ses droits jusqu'à maintenant... Pensez-vous que cela soit dû à la faible performance de leurs actions en bourse actuellement ? ;-) Ou au fait que leur brevet ne sera bientôt plus valide (durée de validité d'un brevet : 17 ans depuis qu'il a été accordé selon l'ancienne loi (donc fin de validité en 1987+17=2004), 20 ans depuis le dépôt de la demande selon la nouvelle loi (donc fin de validité en 1986+20=2006)).

          En ce qui concerne les formats d'image "à perte", il existe aussi le JNG (créé par le même groupe que le PNG). Il ne fait toutefois qu'encapsuler un flux JPG dans une structure PNG. Je ne sais donc pas du tout où situer le JNG par rapport au brevet dont on discute ici. (La spécification du JNG est disponible à : http://www.libpng.org/pub/mng/spec/jng.html(...) .)

          Déni standard : je ne suis pas un avocat spécialiste des brevets, donc je peux très bien me tromper dans l'interprétation du jargon volontairement flou utilisé dans les demandes de brevet (toutefois je m'intéresse depuis quelques années au sujet et je pense donc que mon interprétation est assez correcte) ; je n'ai pas lu l'intégralité de leur demande de brevet (c'est soulant à lire), il peut donc y avoir des passages qui se rapportent plus au JPG qui m'aient échappé.

          Zeiram
    • [^] # Re: ====> Moment correcteur orthographique <====

      Posté par  . Évalué à -2.

      a recupéré
      a récupéré

      A la limite,
      À la limite,

      Daisolé!! CT presk bon mé votre Moment viends d'être refusaient par le validator.

      Your document will now be parsed by the
      grammatical scrutinizer. Please Wait...
  • # Rappel qui s'impose sur GIF,PNG et JPEG

    Posté par  . Évalué à 10.

    Le gif est un format de compression non destructif basé sur une palette de couleurs, et sur la répétition de la couleur dans l'image. Plus les couleurs sont répétées plus il y a de gains possibles. Il n'y a qu'une compression possible, sans pouvoir compresser d'avantage en sacrifiant la qualité. Initialement, la palette faisait 256 couleurs au maximum, on l'utilise donc pour tout ce qui est dessin/logos, où ca ne pose pas de problème. Moins on met de couleurs (2/4/8/16/32/64/128/256) moins il faut de bits pour l'exprimer (1/2/3/4/5/6/7/8 bits). Par contre pour faire 16 mio de couleurs, il faut 24 bits donc 3 fois plus de place qu'en 256 couleurs.

    Le PNG est basé sur le meme principe, en un peu plus efficace. Il y a plusieurs taux de compression possibles, mais il faut choisir entre rapidité de codage/décodage et taille, ce qui est basé sur une optimisation du code de compression. Pas de merveilles à en attendre donc, la différence fait 10% à tout casser. C'est toujours du non destructif, donc pas moyen de gagner davantage au dépens de la qualité.

    Le JPG lui est très différent et beaucoup plus complexe. Pas besoin de palette. Pourquoi ? Parce qu'on n'essaye pas de restituer l'image "pixel par pixel", mais "carré par carré". Une image JPEG est l'addition d'une multitudes de carrés. Le cas typique c'est un visage : avec un gros carré rose pale au milieu, et une dizaine de petits carrés rose plus foncé au tour, hop on a une joue !

    11 éléments = une joue. Alors qu'il aurait fallu plusieurs centaines d'éléments pour faire une joue si l'élément est le pixel.

    Bien sur c'est plus grossier, mais on gagne tellement de places qu'en échange on peut mettre le paquet sur les couleurs, car on ne doit la préciser que 11 fois au lieu de plusieurs centaines dans l'exemple. Conséquence : on n'a meme pas besoin de prévoir moins de 16 Mio de couleurs. En plus il y a un moyen tout simple de faire varier la taille/qualité de l'image :
    -plus les carrés sont grands plus l'image est légère et mauvaise
    -plus les carrés sont petits plus l'image est lourde et bonne.
    Le très grand taux de compression en fait un format de choix pour les photos.
    Mais le fait qu'ils soit basé sur des carrés fait qu'il a du mal à rendre les courbes, d'ou les pbs de flou autour des textes par exemple.
    L'autre contrepartie c'est que le temps de codage/décodage est beaucoup plus lourde, on s'en rendait facilement compte il y'a 5 ou 6 ans, maitenant les machines modernes il n y'a plus de pb.


    En résumé :
    - le GIF/PNG est très mal adapté aux images avec peu de répétitions de couleurs différentes. Donc les photos avec leurs dégradés en milliers/millions de couleurs ne sont pas du tout adaptées à ca. Par contre pour les logos, dessins, textes c'est parfait d'autant plus que la qualité est préservée à 100%
    - le JPG est très mal adapté aux petits motifs, détails, couleurs uniformes, qu'il a du mal à retranscrire fidèlement avec des carrés.

    Tout ceci pour dire que non le PNG ne pourra jamais remplacer le Jpeg, et qu'on aura toujours besoin de 2 formats d'images différents, car ces 2 types d'images n'ont rien à voir. Idéalement si on pouvait faire un format commun efficace, il ne sera jamais aussi bon que le Jpeg dans les photos, ou que le PNG dans les logos.
    • [^] # Re: Rappel qui s'impose sur GIF,PNG et JPEG

      Posté par  . Évalué à -2.

      Ben là je dis bravo.
      voilà au moins une explication qui a le mérite d'être claire et précise.
      Merci pour ses rappels/éclaircisements qui en auront intéréssés plus d'un je pense ;-)
    • [^] # Re: Rappel qui s'impose sur GIF,PNG et JPEG

      Posté par  (site web personnel) . Évalué à 8.

      Ou laors il faudrait qu'un m^me format dispose de 2 schemas de compressions en fonction du rendu demandé (schema ou image).

      "La première sécurité est la liberté"

      • [^] # Re: Rappel qui s'impose sur GIF,PNG et JPEG

        Posté par  . Évalué à 8.

        ... 2 schemas de compressions en fonction du rendu demandé ...

        mais c'est possible !

        tu prends tu TIFF. tu peux compresser ton image a l'interieur du fichier en LZW (brevete) pour tes dessins, et en JPEG (brevete aussi apparament) pour tes photos !

        quel epoque merveilleuse :-[
        • [^] # Re: Rappel qui s'impose sur GIF,PNG et JPEG

          Posté par  (site web personnel) . Évalué à 4.

          quel interet ? ca revient bien à avoir deux formats en interne, deux lib de compression/décompression. La seule chose que ca change c'est d'avoir une extension unique.
          • [^] # Re: Rappel qui s'impose sur GIF,PNG et JPEG

            Posté par  . Évalué à 7.

            L'interet c'est que quelque soit le format de compression, le domaine reste le meme : celui d'un espace discret a deux dimensions dont les valeurs sont plus ou moins restreintes en fonction de la profondeur des couleurs (anglicisme), bref du nombre de bits par pixel. Des tas d'autres formats permettent comme cela d'avoir un format de compression different pour chaque fichier comme AVI quicktime et ogg par exemple, dont le seul but est de coder des donnees variables dans le temps. Apres, on specifie quel domaine varie dans le temps (son, image, les deux) puis l'algo de compression utilise. Mais le format reste le meme.

            Bref, c'est relativement propre comme approche, c'est un format d'encapsulation.


            (desole pour les accents, terminal vt100 de merde+lynx)
    • [^] # Re: Rappel qui s'impose sur GIF,PNG et JPEG

      Posté par  . Évalué à 10.

      ou la la ! excuse moi, mais c'est pas ca du tout pour le jpeg. (le reste me parrait bien)

      Le JPG lui est très différent et beaucoup plus complexe. Pas besoin de palette. Pourquoi ? Parce qu'on n'essaye pas de restituer l'image "pixel par pixel", mais "carré par carré".

      effectivement on code l'image par paquet de 8x8 informations par plan de couleur (sachant qu'on peut faire du monochrome a partir d'images 8bpp ou de la couleur avec des 24bpp)

      Une image JPEG est l'addition d'une multitudes de carrés. Le cas typique c'est un visage : avec un gros carré rose pale au milieu, et une dizaine de petits carrés rose plus foncé au tour, hop on a une joue !

      11 éléments = une joue. Alors qu'il aurait fallu plusieurs centaines d'éléments pour faire une joue si l'élément est le pixel.


      pas du tout. tu décris (avec tes mots :-), une compression par fractales.

      En fait, l'algo c'est plutot :

      pour chaque carre de chaque composante :
      on le passe dans le domaine de fourrier. Puis on divise chaque element par une valeur entiere (l'ensemble des diviseurs s'appelle la table de quantification). Bon. on est dans le domaine de fourrier, ok ? donc le but c'est d'associer aux hautes frequences un coefficient de quantification eleve, (ils contiennent moins d'informations perceptibles a l'oeil) -> les hautes frequence a 0.

      Tout ca pour maximiser le nombre de zeros dans notre carre 8x8. ensuite pour le stocker ce petit carre, on le parcours en zig-zag pour avoir tous les coeff de haute frequence ensemble (tous les zeros ensembles). et on compresse avec un algo type huffman.

      voila ! je suis d'accord c'est moins sexy que ton explication. mais c'est un peu plus "juste"

      en resume : on stocke que les basses frequences dans chaque carre 8x8.

      pour ceux que ca interesse le facteur de compression du jpeg est une coef que l'on multiplie a la table de quantification. c'est pour cela que quand il est au max, t'as pas de variation de couleur dans ton carre (toutes les frequences/variations sont nulles)
    • [^] # Heu, bof ton explication

      Posté par  . Évalué à 8.

      Faut pas confondre MPEG et JPEG. La principale caractéristique de JPEG est non pas de travailler sur des carrés, mais d'utiliser une représentation fréquentielle de l'image (transformée en cosinus discret ou DCT, qui s'apparente sur le principe à une transformée de Fourier). Dans cette représentation fréquentielle on profite des propriétés du système psycho-visuel pour appliquer différentes quantifications selon les fréquences. Ainsi les fréquences faibles (jusqu'à la fréquence zéro qui représente la composante continue de l'image, i.e. la valeur moyenne des valeurs RGB) seront codées assez précisément (par exemple 8 bits), alors que les fréquences élevées, qui correspondent aux transitions, seront codées sur un nombre beaucoup plus réduit de bits (2, 3, 4...). Du coup les schémas, logos, textes, qui sont constitués de principalement de traits donc de transitions rapides, donc dont toute l'information utile se situe dans les fréquences élevées, rendront très mal en JPEG.

      Il faudrait vérifier, mais il est probable que le JPEG effectue en sus une transformation RGB -> YUV, où Y est la luminance, et U et V deux composantes de chrominances. En effet l'oeil est plus sensible à la luminosité, donc U et V seront en outre codées sur moins de bits (en télé numérique on parle souvent de codage 4-2-2 par exemple : 4 bits de luminance et 2 bits pour chaque composante de chrominance).

      Enfin, du côté de l'audio, la lecture des documents présents sur le site-mère de Ogg Vorbis sont très intéressants aussi, sur le type de compressions effectuées.... (voir http://www.xiph.org(...) )
  • # C'est voulu ?

    Posté par  . Évalué à -3.

    ... la pub pour un appareil photo numérique juste au dessus de l'article de dpreview ? en tout cas, c'est du plus bel effet...
  • # Moi aussi je veux devenir riche !

    Posté par  . Évalué à -2.

    Je me propose de breveter la compression qui consiste à supprimer les accents de la langue française dans les textes écrits sur Internet (en effet, le jeu de caractères est plus restrient, donc cela compresse).

    Vais-je m'enrichir rapidement ?

    ;)
  • # Et il y en a qui payent ?

    Posté par  (site web personnel) . Évalué à 8.

    En ce moment, chez confo, j'emporte tout chez moi sans payer...

    Un peu comme les jpeg l'année dernière, yavait un brevet dessus mais on me disait que l'utilisation était gratuite.

    Seulement chez confo, ils écrivent bien sur la pub que dans six mois, il faudra payer. au moment ou j'emporte mon canapé, je signe des papiers comme quoi je sais qu'il me faudra payer plus tard et que je ne pourrais pas dire que je n'en était pas informé.

    Je n'arrive pas a comprendre comment Forgent peux arriver à justifier son revirement de pisitionnement. D'accord l'algo. leur appartient mais s'ils voulait le rendre payant n'auraient-ils pas du en informer les utilisateurs au moment de sa mise sur le marché ?
    • [^] # Re: Et il y en a qui payent ?

      Posté par  (site web personnel) . Évalué à 9.

      c'est pas tout a fait un revirement de position,
      Forgent a rachete Labs qui avaient le brevet, et
      n'en seraient que le beneficiaire, pas le 'createur' (notez les guilemets)

      PS: j'utilise pas les accents, je dois payer aussi? ^_^
      • [^] # Re: Et il y en a qui payent ?

        Posté par  . Évalué à 1.

        euh... Dis-moi si je me trompe mais... c'est pas des guillemets que t'as mis, là... c'est des apostrophes... ;)

        ça va g compris -1
  • # Une alternative à JPEG, sans standard (à ma connaissance)

    Posté par  . Évalué à 3.

    JPEG est basé sur la DCT (discrete cosine transform).. qui est un peut daté. Depuis, on a vu que les ondelettes, ca rox. Le problème est qu'il n'y a pas, à ma connaissance de standard basé sur cette technologie.

    En plus, JPEG a plusieurs moutures, et il faudrait savoir laquelle est protégée. Pour plus d'infos
    http://www.jpeg.org/public/jpeghomepage.htm(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.