Diskussion:JPEG 2000/Archiv

message: 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)
replies: text: * 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)
thread_title:  Unterschied zu jpg 

message: * 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)
replies: text: 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)
thread_title:  "Vorteile gegenüber JPEG sind" 

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

message: 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)
replies: text: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Bildqualität wirklich besser ? 

message: 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)
replies: text:  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)
thread_title:  Beispieldateien als JPG? 

message: 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)
replies: text:  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)
thread_title:  Transparenz?! 

message: 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)
thread_title:  Lizenz 

message: 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)
thread_title:  Summer of Code 

message: 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)
thread_title:  Metadaten (ICC-Profile, IPTC...) 

message: * "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)
thread_title:  Einleitung 

message: * "JPEG2000 ist ein ist ein Grafikformat wie zB auch PNG, GIF, ............."; mir fehlt der gemeinsame Bezug
--Abonino 11:58, 20. Jun. 2009 (CEST)
thread_title:  Einleitung 2 

message: 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)
replies: text: * 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)
replies: text: * 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)
thread_title:  Vorteile gegenüber JPEG 

message: 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)
thread_title:  Stufen der Kompression 

message: 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)
thread_title:  Beispielbilder 

message: 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)
thread_title:  Artikel mit grosser Lücke? 

message: 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)
thread_title:  "Nach der iHQC-Technologie die zweitbesten Komprimierungsraten" 

message: 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)
replies: text: 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)
replies: text: Jetz' nich' mehr.--Psycho Chicken (Diskussion) 09:00, 6. Sep. 2016 (CEST)
thread_title:  Ungünstige Beispielbilder