Diskussion:JPEG 2000/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:JPEG 2000/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:JPEG_2000/Archiv#Thema_1

Link zu Luratech

Warum wird die auf der offiziellen Webseite der Joint Photographic Experts Group verlinkte Referenzimplementation von Algovision-Luratech mit dem lapidaren und inkompetenten Kommentar "rm junk link" entfernt? Doch hoffentlich nicht, weil sie nicht unter der GPL steht und Geld kostet? :( HALLO, das ist DIE kommerzielle Implementation schlechthin, wenn sowas nicht erwünscht ist, müsste auch der Link zur PDFLib im PDF-Artikel rausfliegen. => Link zur Joint Photographic Experts Group hinzugefügt, wo wiederum ein Link zu Algovision-Luratech ist. Hoffentlich geht das mit dem hohen Anspruch dieses Projekts, was als "junk" angesehen wird und was nicht, konform. :(

• Erst einmal, weil die Beschreibung des Links "Diverse auf Wavelets beruhende Software, u.a. ein Freeware-Konversionprogramm nach JP2" darauf hindeutete, dass es sich um einen Link handelt, der nur am Rande mit JPEG 2000 zu tun hat. Wenn da etwas von "Referenzimplementation" gestanden hätte, hätte der Link eine bessere Chance gehabt, aber...
• Der Link ist aber wirklich junk, vielleicht ist es nicht die korreke URL des Ladens? Wenn ich dem Link folge, gelange ich per HTTP redirect auf www.astrologylist.com und dort steht wirklich nichts von JPEG 2000.

Pjacobi 09:02, 6. Jun 2005 (CEST)

• Hast recht, der Link ist veraltet. Die Domain wurde offenbar aufgegeben, deswegen steht da jetzt Müll. Ich weiß es auch nicht, wahrscheinlich sollte der Link doch weg.
• Anderer Vorschlag: Vielleicht sollte man ImageMagick aufnehmen. ImageMagick ist eine sehr weit verbreitete Software, d.h. die Relevanz dürfte ausreichend für eine Erwähnung hier sein. ImageMagick wird überall für serverseitige Bildbearbeitung benutzt und ist, soweit ich weiß, eine von ganz wenigen Möglichkeiten, JPEG 2000 auf UNIX-Systemen anzuschauen und zu erzeugen. Wenn IrfanView und XnView eine Erwähnung wert sind, dann könnte das auch für ImageMagick gelten.

-- 217.246.179.86 13:21, 18. Jun 2005 (CEST)

Unterschied zu jpg

Mich würde interessieren, wie die besseren Kompressionsergebnisse im Vergleich zu JPG erreicht weden. liegt es an dem in der klassischem JPG-Kompression fehlenden Sinus-Term, oder was? Kolossos 10:37, 15. Dez 2005 (CET)

• Der Sinusterm der Fouriertransformation fehlt, weil die Cosinustransformation benutzt wird. Der 8x8-Block wird zuerst in all Richtungen gespiegelt, so dass der resultierende 16x16 Block symmetrisch bezueglich seines Mittelpunktes ist ("gerade"), daher gibt es keine ungeraden (sinus) Komponenten mehr.

Und werft mal einen Blick auf Bild_Diskussion:Pisagrabmal_66fach_jp2_2.jpg.Kolossos 18:20, 16. Dez 2005 (CET)

"Vorteile gegenüber JPEG sind"

• Nervig! Ständig wird der Artikel editiert und so geändert das dort steht dass das alte JPEG noch keinen progressiven Bildaufbau konnte.

• Das ist 100% komplett und absolut falsch! Die Sache ist folgende: in JPEG war der progressiver Bildaufbau noch optional, erst im JPEG 2000 Standard ist er als Pflicht vorgeschrieben. Und nein, es ist zwar ein optionales aber kein exotisches Feature, wie weiter unten erwähnt können inzwischen schon einige Programme (auch bekannte, keine Nischensoftware), problemlos JPEGs mit progressivem Bildaufbau abspeichern und progressiv anzeigen. Quelle (z.B.): http://www.tecchannel.de/test_technik/grundlagen/401069/index2.html

• progressiver Bildaufbau möglich (Je mehr vom Bild geladen ist, desto mehr Details zeigen sich).

• Also dieses progressive ist doch letztendlich eine Frage des Dateiformates, ob zuerst die niederfrequenten Anteile und dann die hochfrequenten drinstehen. Ich weiss nicht, ob es schon im JFIF (jpeg file interchange format) definiert ist, aber seit Jahren koennen doch eigentlich alle Browser progressive jpegs anzeigen, oder ? Scheint mir also keine besondere Neuerung von 2000 ?

• Ich denke, dass genau das, also die so genannte Scalability, einer der wichtigsten Vorteile von JPEG 2000 ist. Wenn das Bild vollstaendig vorliegt kann man dadurch bspw. sehr effizient niedrigere Aufloesungen, geringere Qualitaet, einen Bildausschnitt oder eine beliebige Kombination daraus effizient dekomprimieren. Das heisst es funktioniert auch mit sehr sehr grossen Bildern. Die Reihenfolge der Daten in einer Datei ist bei der komprimierung relativ frei waehlbar. Es existiert auch ein Protokoll (JPIP) mit dem sich Teile eines JPEG2000 Bildes uebertragen lassen. Bsp: Mit folgender URL kann man aus einem Bild mit einer Aufloesung von 4000x6000pix einen 100x100pix Ausschnitt an Position 2400,1400 mit halber Aufloesung erhalten: jpip://server.tld/bild.jp2?fsiz=2000,3000&rsiz=100,100&roff=1200,700 --134.109.116.153 21:53, 7. Mai 2006 (CEST)

• Raum für Metadaten

Auch eine Frage des Dateiformats, auch jfif siehe "application marker" im header vor, z.B. schreibt jede Digitalkamera ihren Namen, Datum, usw. rein. Oder gibt es einen wesentlichen Unterschied ?

Ein wesentlicher Unterschied scheint mir allerdings zu sein, dass man nicht die 8x8 Blockartefakte sieht !

Hier finde ich gerade einen link zum Vergleich, vielleicht mag das ja jemand nochmal aufarbeiten: http://www.tecchannel.de/entwicklung/grundlagen/401069/index2.html

Meines Erachtens gibt es noch einen weiteren Vorteil, nämlich daß das wiederholte Öffnen, Bearbeiten und Speichern von JPEG2000-Bildern bei gleichen Kompressionseinstellungen und gleichem Encoder nicht mehr mit wesentlichen Qualitätseinbußen einhergeht. So kann man es auch zur Zwischenspeicherung verwenden. --- Ebbelheinz 18:38, 13. Jan. 2007 (CET)

Überarbeiten

weblinks im fliesstext auf auf „ref“ umgebaut, siehe auch Wikipedia Diskussion:Weblinks#JPEG 2000 --W!B: 13:42, 2. Apr 2006 (CEST)

Bildqualität wirklich besser ?

Vor einiger Zeit schrieb ich diesen Artikel und stellte fest, das JPEG & JPEG2000 ihre Vor- und Nachteile besitzen. Nach einem Serverwechsel waren die u.a. Beispielbilder weg, so dass ich sie neu anlegte. JPEG mit Qualitätsstufe 25, also hohe Kompression. JPEG2000 so komprimiert, dass ungefähr die selbe Dateigröße entsteht wie bei JPEG. Achtung! Das "Original" ist auch JPEG komprimiert, das ist soweit ich weiß, bei DigiCams so. Dieser Formatvergleich hinkt also ein bischen, dennoch sind die Unterschiede gut zu erkennen.

Orignal JPEG JPEG2000

Ergebnis: JPEG2000 produziert augenscheinlich das bessere Bild!

Da man aber üblicherweise eine Qualitätsstufe von 75 aufwärts wählt und Speicherplatz heutzutage im Überfluss bereitsteht, ist JPEG, was das Archivieren von Bildern und dessen Qualität angeht, für den Normalverbraucher wirklich mehr als ausreichend. Will sagen, JPEG2000 braucht im Moment eigentlich niemand. Es gibt dieses Format nun schon so lange, aber es will sich einfach nicht wirklich durchsetzen. Das spricht, denke ich, für sich. Nur Leute, die höchste Anprüche an Bildqualität, Kompression und Weiterverarbeitbarkeit ihrer Bilder stellen, benutzen möglicherweise dieses Format.

Also ich weiss nicht. Ich habe mir das landschaftsbild unten ("original"; übrigens, eine so schlechte JPEG-kompression wie nebendaran habe ich mit dem IrfanView - auf 80% - noch nie produziert). Im bitmap abgespeichert 200 KB, JPEG 80% (IrfanView) 13 KB und kaum sichtbarer unterschied, JP2 verlustfrei 84 kB, JP 100% 26 KB, 90% 22 kB, 60% 13 KB, also gleich gross wie das als sehr gut zu bezeichnende 80% JPG, jedoch in einer deutlich schlechteren qualität: feine strukturen wie nachm entrauschen verwischt (seegrund, weidengebüsch; kommt in leichteren form schon bei JP2 90%), haardünne linien im oberen himmelbereich.

Also mein fazit: Nur die verlstfreie möglichkeit wird für mich offenbar wertvoll, sonst bleibe ich lieber bei JPEG, die resultate scheinen eindeutig besser zu sein. Allerdings solange ich keine JP2-möglichkeit für mehr als 640x480 habe, das verkleinern auf diesen format nur um verlustfrei abspeichern zu können, wird kaum sinn machen. -- 89.217.2.149 07:59, 12. Nov. 2006 (CET) MW1954

Die Bildqualität von JP2 scheint auch wesentlich vom verwendeten Encoder abzuhängen. Das LurawaveJP2-Plugin für Photoshop kann man vergessen, es erzeugt bei gleicher Dateigröße wesentlich schlechtere Ergebnisse als das IV-Plugin oder gar J2K. -- Ebbelheinz 18:48, 13. Jan. 2007 (CET)

Ich habe das J2K-Plugin mal ausprobiert und eine hochauflösende tiff 3D-Computergrafik als Vorlage genommen. Die Unterschiede waren deutlich! Bei gleicher Dateigröße war JPEG 2000 immmer besser. Besonders in dunklen Bereichen und bei der Schärfe. Leider wird es so gut wie nicht unterstützt und das Problem mit den Encodern wurde schon angesprochen. JPEG 2000 braucht beim laden etwas länger als JPG ^^ Das hat mir InfranView gesagt und gemerkt hat man es auch. - Metoc ☺ 15:06, 15. Jan. 2007 (CET)

Kommentare zum Thema Bildqualtität (Details bitte an mich: thor@math.tu-berlin.de): Die "visuelle" Bildqualität hängt sehr deutlich vom Codec und von den Codec-Optionen ab. Die auf der Seite liegenden Beispielbilder geben das leider recht ungenügend wieder, ich könnte gerne bei Interesse obigen Bild einmal mit verschiedenen Optionen durchkomprimieren und die Resultate hier präsentieren. Insbesondere sollte man dazu besser nicht den JasPer verwenden... Die freien Codecs (JasPer und JJ2000) optimieren auf PSNR, was aber nicht wahrgenommener Bildqualität entspricht, hierfür gibt es "unfreie" Implementierungen, die hier deutlich(!) bessere Resultate liefern. Entsprechende Messungen wurden und werden hierzu auch vom JPEG Kommittee durchgeführt. Benutzer: Thomas Richter, 8. April 2009 (nicht signierter Beitrag von 141.58.47.62 (Diskussion | Beiträge) 13:07, 8. Apr. 2009 (CEST))

Beispieldateien als JPG?

die Beispieldateien von diesem römischen Teil die zeigen sollen dass die Qualität besser ist als die von jpg sind in jpg gespeichert... wie soll ich das verstehen? wie kann man mit einem verlustbehafteten Format den Nachteil genau dieses Formats gegenüber einem anderen Verlustbehaftetem Format zeigen? Hat vielleicht jemand das Original von dem Bild (verlustfrei)? Dann könnte man das ja mal richtig machen und hier als z.B. als PNG speichern (verlustfrei).

Prinzipiell ist der Einwand natürlich richtig, man kann in dem JPEG2000-Beispiel jedoch keine JPEG-Artefakte erkennen, weil dafür der Kompressionsgrad zu gering ist. Deutlich zu erkennen sind die Unterschiede in Blockbildung bei der einen und Verwaschung bei der JPEG2000-darstellenden-Variante. -- Ebbelheinz 14:34, 15. Jan. 2007 (CET)

Als Beispiel braucht man am Besten ein technisch perfektes und verlustfrei aufgenommenes Bild. Ich komme da leider nicht ran. An denjenigen ein Lob, der sich die Zeit nahm für die Erstellung des Vergleichs in png. Nur das der Ausschnitt 200% vergrößert wurde ist nicht schön. DerBerg ist ja ganz kantig ;) Vielleicht versuch ich mich auch mal. Aber wie Ebbelheinz sagte, die prinzipiellen Unterschiede kann man erkennen. - Metoc ☺ 15:16, 15. Jan. 2007 (CET)

Keinerlei Links zu Software?

Irgendwie versteh ich das nicht: Sind denn Links zu Jpeg 2000 Implementierender Software grundsätzlich böse? Oder warum killt Complex die für mich interessanten Links? Fragen über Fragen -- Frogger67 Complex 23:53, 4. Mai 2007 (CEST)

Mit einer Antwort: Wikipedia:Weblinks Grüße Complex 23:53, 4. Mai 2007 (CEST)

Hab ich gelesen, nichts darin scheint mir Links auf Software zu verbieten.

Also bitte erklär mir das näher. (Auch wenn's für Dich uu klar ist, manch anderer scheint das auch nicht zu verstehen sonst wären die Links nie eingebaut worden) -- Frogger67

"Weblinks sollen es dem Leser ermöglichen, sein Wissen über den Artikelgegenstand zu vertiefen." - Das wird durch Links auf Softwareprodukte nicht erreicht. Weiterhin gehören Links wie dieser ganz sicher nicht zum Feinsten, was das Web zum Thema JPEG 2000 zu bieten hat. --Complex 00:06, 5. Mai 2007 (CEST)

Gerade Links zu Software können bei diesem Thema sehr helfen das Wissen über den Artikelgegenstand (ganz praktisch) zu vertiefen!--Mjh 08:01, 9. Jan. 2009 (CET)

Ok, Ich als Nutzer erwarte mir aber auch minimale Informationen zb darüber ob das Fileformat üblicherweise im Browsern unterstützt wird, und wenn nicht Links zur Abhilfe dh den Plugins... -- Frogger67 00:10, 5. Mai 2007 (CEST)

Dann sollte das in den Artikel eingearbeitet werden. Genau. --Complex 00:27, 5. Mai 2007 (CEST)

Transparenz?!

Also entweder ich lese nur Schundwebseiten, oder JPEG 2000 unterstützt Alphatransparenz. Wenn das so ist, wieso wird es dann nirgendwo im Artikel erwähnt? Das ist dann doch DER Vorteil schlechthin im Vergleich zu JPEG!

• laut http://www.axialis.com/tutorials/tutorial-iw020.html kann man es --77.184.35.72 01:41, 5. Jan. 2008 (CET)

In der Tat unterstützt JPEG 2000 Alphakanäle. (nicht signierter Beitrag von 141.58.47.62 (Diskussion | Beiträge) 13:07, 8. Apr. 2009 (CEST))

Lizenz

Im Artikel steht, dass es wg. bestimmten Lizenzproblematiken nicht so oft frei verwendet wird. Was hat es damit auf sich? Danke, -- 77.75.201.70 21:08, 25. Aug. 2009 (CEST)

Summer of Code

Also der "Summer of Love" war schneller vorbei. Irre ich mich? Vielleicht schreiben wir zu Firefox so was wie "hätte beinahe sein können, dass...". Wenn ich mal in Rente bin, kümmere ich mich vielleicht auch um solche Software-Projekte. Zu den Leuten, die 2007 (die Älteren werden sich erinnern), damit begonnen haben, habe ich leider keinen Kontakt. Gibt's was neues?--Psycho Chicken 11:13, 25. Sep. 2009 (CEST)

Metadaten (ICC-Profile, IPTC...)

Welche Arten von Metadaten kann Jpg2000 eigentlich speichern? Also IPTC, ICC-Profile, EXIF, XMP... Afaik ist zumindest IPTC vorgesehen, aber die gerne verwendete JasPer-Bibliothek unterstützt angeblich keine Metadaten. Photoline verwirft ICC-Profile, IPTC- und Exif-Daten. Eventuell wäre es nützlich, in der Rubrik "Unterstützung" bei den Programmen entsprechende Einschränkungen zu erwähnen. (Frank/Hoogo) -- 80.139.0.244 19:56, 16. Nov. 2009 (CET)

Überarbeiten

Hallo liebe Wikipedia-Kollegen. Ich würde den Artikel gerne überarbeiten. Damit sich niemand auf den Schlips getreten fühlt und die Änderungen nicht wieder rückgängig gemacht werden möchte ich die Punkte hier vorher diskutieren. Bitte korrigiert meine Fehler und gebt Euren Senf dazu ab. (nicht signierter Beitrag von Andre G (Diskussion | Beiträge) 12:04, 25. Jul. 2008 (CEST))

Einleitung

• "Mit dem Standard lassen sich sehr gute Komprimierungsraten"

• Die Aussage "sehr gut" ist relativ, daher würde ich die gerne rausnehmen. Wer definiert denn was eine "gute" und was eine "schlechte" Kompressionsrate ist? Im Kontext klingt der Satz so als seien die Kompressionsraten für verlustfreie Kompression schlecht.

• "für verlustbehaftet zu speichernde, fotoähnliche Bilder "

• Stimmt so direkt beides nicht. j2k ist auch für verlustfreie Kompression und für _nicht_ fotoähnliche Bilder gedacht, z.B. ausdrücklich für gescannte Schriften, Bilder mit harten Farbübergängen, etc.

• "Das Format kann eine Reihe von Metadaten aufnehmen"

• JPEG2000 ist kein Format und kann daher auch keine Metadaten aufnehmen. Der Standard spezifiziert ein optionales Dateiformat namens JP2, dass auch Schutzrechte und Metadaten aufnehmen kann. (nicht signierter Beitrag von Andre G (Diskussion | Beiträge) 12:04, 25. Jul. 2008 (CEST))

Einleitung 2

• "JPEG2000 ist ein ist ein Grafikformat wie zB auch PNG, GIF, ............."; mir fehlt der gemeinsame Bezug

--Abonino 11:58, 20. Jun. 2009 (CEST)

Vorteile gegenüber JPEG

Den Vergleich mit JPEG als ersten Abschnitt im Artikel zu haben halte ich für ungünstig. Es sollte erst einmal das Verfahren an sich beschrieben werden, also vielleicht der Aufbau des Kodierers bzw. Dekodierers, oder vielleicht die Motivation für den neuen Standard.

• bessere Komprimierungsrate bei gegebener Qualität

• Eine solche Aussage legt ein Qualitätsmaß zu Grunde. Welches Maß ist hier angesetzt worden? Man könnte hier vielleicht mit der PSNR argumentieren, aber selbst dafür lassen sich leicht Gegenbeispiele finden. Sollte subjektive Qualitätseinschätzung gemeint sein ist es ebenfalls problematisch, viele Leute halten z.B. die gewisse Weichzeichnung für inakzeptabel. (nicht signierter Beitrag von Andre G (Diskussion | Beiträge) 12:04, 25. Jul. 2008 (CEST))

• Ich habe mit einigen hochauflösenden (8 MP) Fotos experimentiert und zumindest die jp2-Implementierung von Luratech ist meiner Meinung nach sogar qualitativ schlechter als .jpg bei gleicher Dateigröße. Ich konnte bei den meisten Bildern mehr Details in der .jpg - Version erkennen. Das Originialzitat ist nicht mit Quellen belegt und meiner Erfahrung nach falsch. Kann jemand Quellen liefern, bzw. den Eintrag sonst löschen ? Boardersparadise 21:31, 2. Sep. 2008 (CEST)

• Welchen Eintrag meinst Du jetzt genau? Ich habe ebenfalls mit einigen Fotos "experimentiert", und konnte keine solchen Mängel erkennen. Hast Du den Quellen für Deine These? Signal/Rausch Verhältnisse z.B.? Andre Gemünd 15:44, 28. Nov. 2008 (CET)

Stufen der Kompression

Die Überschrift klingt für mich nach Qualitäts- oder Kompressionsstufen. Vielleicht sollte man das "Aufbau des Kodierers" nennen, oder "Ablauf der Kompression". Häufig wird das auch noch unterteilt in Subbitplane Coding, Arithmetic Coding und Bitstream Assembly.

Anschließend würde ich gerne die verschiedenen Module leicht erklären. Ich weiß allerdings noch nicht in welchem Umfang und wann ich das schaffe. Gibt es die Möglichkeit an einem Entwurf zu arbeiten, den wir dann erst später veröffentlichen? (nicht signierter Beitrag von Andre G (Diskussion | Beiträge) 12:04, 25. Jul. 2008 (CEST))

Verbreitungsgrad und Unterstützung

• "freie Kodiersoftware für den Standard unzureichend verfügbar ist"

• Ich weiß nicht, ob man das so stehen lassen kann. Immerhin gibt es openJPEG, Jasper, FreeImage, etc. (nicht signierter Beitrag von Andre G (Diskussion | Beiträge) 12:04, 25. Jul. 2008 (CEST))

Das Kodieren ist dank dieser Tools wirklich nicht mehr das Problem.

Die mitgelieferten Viewer dagegen tun nur anzeigen und bieten darüber hinaus kein Spektakel. Das ist dann altmodisch. Der OpenJPEG-Viewer ist augenscheinlich nur unter Windows problemlos einsetzbar (kann mich irren). Tatsächlich fehlt es an Browser-Plugins. Hier wieder haben Opera und FF unter Linux die Nase vorn, obwohl das Teil wirklich alt ist. Man braucht vielleicht nur das Release-Datum des Plugins zu verheimlichen und schon ist alles wieder gut... --212.204.119.210 09:51, 18. Aug. 2009 (CEST)

Beispielbilder

Ich habe den schwerwiegenden Verdacht, dass hier als Bildquellen JPEG Dateien verwendet wurden. Es macht natürlich keinen Sinn ein JPEG im Nachhinein mit JPEG2000 zu kodieren, insbesondere wegen der verlustbehafteten Quantisierung in JPEG. Wir sollten also als Quelle beispielsweise ein RAW verwenden, dass dann als JPEG und JPEG2000 komprimieren und das JPEG2000 dann anschließend wieder in ein verlustfreies Format konvertieren. Außerdem sollten vielleicht Bilder verwendet werden, die etwas gezielter auf einen Effekt zugeschnitten sind. Beispielsweise ein breiter Farbverlauf für die Quantisierungseffekte, ein schwarz-weißes Schriftbild für das Ringing, und ein Foto für die Block-Artefakte. (nicht signierter Beitrag von Andre G (Diskussion | Beiträge) 12:04, 25. Jul. 2008 (CEST))

Link zum Standard

Wieso wird denn eigentlich der Standard selbst nicht im Artikel verlinkt? http://www.itu.int/rec/T-REC-T.800-200208-I/en (nicht signierter Beitrag von 81.173.228.175 (Diskussion | Beiträge) 20:05, 21. Jul. 2008 (CEST))

Artikel schreiben

Ein kleiner Tipp: Bearbeite den Artikel auf Deiner „privaten“ Benutzerseite, indem Du dort mit [[Benutzer:DeinBenutzername/Artikelbau]] eine Unterseite anlegst. Sobald Du auf den Link klickst, bist Du schon auf der Unterseite. Natürlich kannst Du statt „Artikelbau“ andere Namen verwenden. Dort kannst du in Ruhe daran arbeiten, bis er die Kriterien auf Wikipedia:Artikel erfüllt. Zur Wahrung der GFDL fügst du einfach {{subst:Temporärkopie}} hinzu. Ist Dein Artikel fertig, kopierst den Inhalt hinüber. Wenn du möchtest, das andere dir bei der Überarbeitung helfen, verlinke ihn hier mit entsprechender Anmerkung. Ansonsten sei mutig, gute Änderungen werden nicht rückgängig gemacht. Wichtig ist, dass du Aussagen durch Quellen begründest: WP:Wie schreibe ich gute Artikel Viele Grüße,--Merlissimo 13:40, 25. Jul. 2008 (CEST)

Artikel mit grosser Lücke?

Der Artikel geht garnicht darauf ein, das es sich bei JPEG 2000 um einen kompletten Standard handelt. Das Bildformat JPEG 2000 ist natürlich ein/das Kernelement, aber der komplette Standard beinhaltet noch 10 weitere Teile, die laut Webseite zwar nicht alle vollständig sind aber schon erwähnenswert und erläuterbar sind. (nicht signierter Beitrag von 85.178.49.111 (Diskussion | Beiträge) 22:43, 16. Jul. 2006 (CEST))

"Nach der iHQC-Technologie die zweitbesten Komprimierungsraten"

Habe mir mal paar mit iHQC komprimierte Dateien angeguckt. Meiner Vermutung nach geht das wie folgt vor:

• Bild aufteilen in 2 Bilder, wovon eines Vordergrund- und das andere Hintergrund-Pixel enthält (und die jeweils fehlenden Pixel irgendwie interpoliert werden). Die Information, was nun ursprünglich Vordergrund- und was Hintergrund-Pixel war, wird in einer zusätzlichen 1-Bit-Maske gespeichert.
• Hintergrund per JPEG 2000 komprimieren, Vordergrund als Bitmap in stark reduzierter Auflösung speichern
• Ein PDF erzeugen, in dem das Vordergrund-Bild über dem Hintergrund-Bild liegt und dort, wo ursprünglich Hintergrund-Pixel lagen, diese per Maske durchscheinen lassen.

Scheint also kein eigenständiges Bildkompressionsformat zu sein, sondern eine geschickte Kombination existierender Techniken, die wohl durchaus Vorteile bei Dokumenten, aber kaum bei Fotos bringen dürfte. (Ob das wirklich so ist kann ich mangels verfügbarer Testversion nicht abschließend beantworten).

Beispiel: http://www.ihqc.de/images/tabellen/groessenvergleich.html -> invoiceTDI , im Bereich des blauen Stempels mit roter Schrift auf weißem Grund zeigen sich deutlich die Grenzen des Verfahrens, da es nur 2 Ebenen kennt und dort, wo 3 Farben aneinander stoßen, dann doch wieder ein "Fallback" zur JPEG 2000-Komprimierung notwendig wird. (nicht signierter Beitrag von 195.4.111.141 (Diskussion | Beiträge) 23:21, 1. Aug. 2007 (CEST))

Ungünstige Beispielbilder

Die Beispielbilder mit der liegenden Statue zeigen verschiedene Ausschnitte des Bildes (versetzt bzw. verschieden groß), das .JP2-Beispiel wurde als .jpg in den Artikel eingebunden, wodurch ein weiterer Qualitätsverlust nach der .jp2-Komprimierung erfolgte --- Lieber noch mal anfertigen und dann verlustfrei (.png) abspeichern, ansonsten genügt es m.E. den Ansprüchen an die Aussagekraft in diesem Artikel nicht. Gruß, IP 23:53, 15. Jun. 2011 (CEST) (ohne Benutzername signierter Beitrag von 92.225.25.50 (Diskussion) )

Stelle gerne Beispiele zur Verfügung: http://www.uplawski.eu/france/Cevennen/cev_jp2.html#ergebnisse. --92.141.146.225 17:52, 21. Dez. 2011 (CET)--Psycho Chicken (Diskussion) 09:00, 6. Sep. 2016 (CEST)

Jetz' nich' mehr.--Psycho Chicken (Diskussion) 09:00, 6. Sep. 2016 (CEST)