Jpeg 2000

PGP schrieb:

Wahrscheinlich weil das keinem die Schuhe auszog

Zum Vergrößern anklicken....

Ich meinte die libjpeg9, nicht das gruselige JPEG_XR.

Ich möchte nun aber doch behaupten, dass JPEG2000 besser ist als sein ruf und durchaus seine Daseinsberechtigung hat.
Heute habe ich z.B. festgestellt, dass PNG keine EXIF speichern kann. Die lossless-Variante von JPEG2000 schon. Also 16 Bit, lossless bzw. komprimierbar und EXIF, dabei kleiner als TIFF.

Also mein Photoshop CC 2018 speichert und liest JPEG 2000 problemlos. Gerade ausprobiert. Vielleicht hat sich ja die Lizenzproblematik zum Besseren gewendet...

Was ich zuerst gepostet hatte, war eine Momentaufnahme mit dem Stand von vor einigen Jahren.

Steffen

betazoid schrieb:

Ich möchte nun aber doch behaupten, dass JPEG2000 besser ist als sein ruf und durchaus seine Daseinsberechtigung hat.
Heute habe ich z.B. festgestellt, dass PNG keine EXIF speichern kann. Die lossless-Variante von JPEG2000 schon. Also 16 Bit, lossless bzw. komprimierbar und EXIF, dabei kleiner als TIFF.

Zum Vergrößern anklicken....

Ich schrieb doch schon mehrmals darüber...
Ein 10MP CR2 hat (nur ein Beispiel, aber ein reales) hat 14.235.624 Bytes.
Hat als Tif16 60.624.126 Bytes
Hat als Tif8/LZW 17.260.014 Bytes

Jetzt kommt Faststone Viewer und macht einen Jpeg draus. Die Optionen sind 97, Huffman, ohne Farbsubsampling.
Du mußt über 500% gehen, in der Doppelansicht (eine Seite das Tif8/LZW, die andere das Jpeg) um gelegentlich einzelne Pixel zu finden die im Jpeg anders sind.
Größe: 5.229.459 Bytes

Das ist das Master-Jpeg hier. Gewöhnliche Weitergabe an Techniklaien (keine Pixelpeeper) die solche dann Wow finden, mit 92, Farbsubsampling auf Mittel, Huffman.
Größe: 2.432.444 Bytes

Für die gleiche Quali wie die des 97er Jpegs muß ICH auf ungefähr "160" gehen. Wohlwollend... eigentlich wären 170 erst gleichwertig. Die 160 machen:
4.825.251 Bytes

Macht 404.205 Bytes Unterschied
Der Aufwand (im Vergleich zu Jpeg) für das Codieren ist von den Zeiten her ungefähr 8x so hoch. Für das Decoding ungefähr 3x so hoch.
Und BEIDES ist hier auf einem 2500k mit 4.5Ghz und 8GB RAM (mit den schärfsten 1600er Timings die man sich denken kann) immernoch sehr nervig lang.

Geschweige von kleinen BR-Playern oder ARM Mediarechnern & Co.

Sinnloses verballern von Energie und Lebenszeit. Das waren jetzt "nur" 10MP. Bei 22 MP wirds nicht schneller

Wozu man fertig bearbeitete Bilder in 16bit zu Seite legen will, das weiß ich nicht.

Mit Darktable kann ich als JPEG2000 (12 Bit) exportieren. Als *.j2k oder *.jp2. Gewenview und Gimp können zumindest jeweils eine Version davon seit einiger Zeit einlesen (ganz aktuell ist mein Desktop gerade nicht). Allerdings, CPU-Belastung liegt deutlich höher als bei 8Bit Jpeg, zumindest mein Bild zum Testen (das was gerade zur Hand) kein Unterschied, aber ist auch Aufnahme ohne hohen Kontraste.

Steffen Rentsch schrieb:

Also mein Photoshop CC 2018 speichert und liest JPEG 2000 problemlos. Gerade ausprobiert. Vielleicht hat sich ja die Lizenzproblematik zum Besseren gewendet...

Was ich zuerst gepostet hatte, war eine Momentaufnahme mit dem Stand von vor einigen Jahren.

Steffen

Zum Vergrößern anklicken....

Ist die Endung jp2 oder jpf/jpx?

Mein Problem ist (nochmal): Mein PS erzeugt keine jp2, nur jpf, und damit haben manche Programme ein Problem.

betazoid schrieb:

Mein Problem ist (nochmal): Mein PS erzeugt keine jp2, nur jpf, und damit haben manche Programme ein Problem.

Zum Vergrößern anklicken....

Das ist eigentlich eigenartig ... weil ...

https://www.loc.gov/preservation/digital/formats/fdd/browse_list.shtml#j

... Jpeg2000-Part-1 (der das Jp2 Format beschreibt) auch die Grundlage ist für
... Jpeg2000-Part-2 (der das Jpf-Format beschreibt) ... dort heisst es explizit:
"JPX_FF inherits features from its parent: JP2_FF, JPEG 2000 Part 1 (Core) jp2 File Format"

... und darum wundert es mich ein wenig. Ein Programm das Jpf kann,
sollte eigentlich auch die Bibliotheken zur Erzeugung eines Jp2 beinhalten
(es muss die Funktion natürlich nicht zum Benutzer durchreichen).

Kannst du ein kleines von deinem PS erzeugtes JPF File mal zur Verfügung stellen?

Nachtrag: Ich habe mit PS-Elements-5 mal ein JPF-File erzeugt (kann PSE nämlich auch) ...
und dabei habe ich festgestellt, dass das erzeugte File überhaupt kein Jsf (also Jpg2000-Part2)
zu sein schein, sondern ein Jpg2000-Part1 (also Jp2).
Den Vergleich habe ich mit dem "file" Kommando aus minsys gemacht, dass mit bei
jp2-files aus Irfanview "Jpeg 2000 Part 1" anzeigt,
bei jpm-files aus Irfanview wird "Jpeg 2000 Part 6" angezeigt
bei jp2-files aus Faststone wird "Jpeg 2000 Part 1" angezeigt ...
und bei jpf-files aus PSE5 wird "Jpeg 2000 Part 1" angezeigt.

Möglicherweise ist also nur die Dateiendung falsch, die PS dranmacht, der Inhalt ist
aber ein jp2 ... du könntest ja mal schlichtes umbenennen der Endung probieren und dann
versuchen ob die Dateien dann akzeptiert werden.

PGP schrieb:

...
Für die gleiche Quali wie die des 97er Jpegs muß ICH auf ungefähr "160" gehen. Wohlwollend... eigentlich wären 170 erst gleichwertig. Die 160 machen:
4.825.251 Bytes

... immernoch sehr nervig lang.

Zum Vergrößern anklicken....

Um das nachzuvollziehen, musste ich statt Irfanview mal Faststone nehmen
(was ja eh immer so hoch gelobt wird) ... dabei ist mir aufgefallen, dass
Faststone bei der Behandlung von Jpg2000 deutlich langsamer ist, als
Irfanview. Einerseits die Anzeige eines Directories mit Jpg-2000 Bildern
im Thumbnail-Viewer, aber auch die Erzeugung eines einzelnen Jp2-Bildes
aus einem Tif oder Jpg Original ... Irfanview ist schneller.

Möglicherweise ist also ein Teil deiner geäusserten Frustration hier
der Implementierung von Faststone geschuldet.

Ich bin auf Jpeg2000 nicht wirklich heiss, womit sich auch kein "Frust" aufbauen kann

Sonst, kann schon sein.
Bisher ist man es aber gewohnt, daß FS Viewer alles so erledigt wie man es 100% richtig tun sollte. Und bei allen anderen Formaten auch alles andere als Fußlahm ist. Ich analysiere damit TIFs von bis zu 330 MP und kenn nichts schnelleres bei solchen Brocken, außer gleich ganzes CS6 zu starten.
Ok, sagt zugegeben trotzdem nichts über die Implementierung (ASM/SSE) der verschiedenen Coder/Decoder...

Ich würde mich aber schon soweit aus dem Fenster lehnen, zu behaupten, für gleiche Quali ist der Coding/Decoding Aufwand bei Jpeg2000 einfach ums Mehrfache größer als beim Jpeg.

PGP schrieb:

Ich würde mich aber schon soweit aus dem Fenster lehnen, zu behaupten, für gleiche Quali ist der Coding/Decoding Aufwand bei Jpeg2000 einfach ums Mehrfache größer als beim Jpeg.

Zum Vergrößern anklicken....

Das stimmt ganz sicher ... höherer Encoding-Aufwänd wäre ja verschmerzbar ... leider ist auch das Decoding betroffen.

Mir ist aber noch etwas anderes aufgefallen:
Wenn man Jpg zwingt (mittels sehr geringer Werte für die Qualität q<10)
sehr kleine Dateigrössen zu erzeugen, dann kommt man irgentwann an
einen Punkt, an dem das Ergebnis deutlich posterisiert ... Jpg2000
posterisiert selbst bei noch deutlich kleineren Dateigrössen nicht.
...
Realistisch ist der Test sicher nicht, da niemand ein z.B. 3000*2000 Bild
mit minimaler Qualität speichern würde, statt dessen würde man eher
ein 900*600 mit höherer Qualität speichern (was im Ergebnis bei
gleicher Zieldateigrösse ansehnlicher ist).

Also, das ist ja eine echt interessante Diskussion geworden! Danke für die vielen konstruktiven Antworten!

Noch zum PS und jpf: Das Problem ist, dass insbesondere Affinity, mit dem ich in letzter Zeit kokettiere, die von PS erzeugten Dateien nicht öffnet. Und ich glaub da war noch irgendein Programm, aber ich weiß nicht mehr welches.
Affinity öffnet jedoch jp2-Dateien, die von anderen Programmen erzeugt wurden, z. B. Photoline.
Ich find das irgendwie schon blöd. Ich meine ich zahle 12x12 Euro im Jahr für PS und da erwarte ich, dass es alles perfekt macht!
Die Dateiendung ist letztendlich egal, zumindest für IrfanView & co.

@RainerT
Das ist richtig bzw. mir insofern bekannt. Wenn man ein 8MB Tif8/Lzw fest auf 100 80KB pressen will, sieht das mit Jpeg2000 merklich besser aus als mit Jpeg.
Bleibt nur die Frage was man damit anfangen will.

Der Vergleich beim Aufwand von Coding/Decoding ändert sich dadurch aber nur unwesentlich. Andererseits lese ich hier zwischendurch was von losless und 16bit, hab das also eher aus der Sicht einer möglichst hohen Qualität betrachtet

Wenn man ggf. wie betazoid hin und her schaufelt (so wie ich das verstehe), eignet sich dafür Tif16 weiterhin bestens.
Das macht zwar knappe 60MB pro 10MP (?), das ist aber für mich nur ein Zwischenergebnis, was man da rumreicht. Ich mache das zwischen Optics und Lightroom ebenfalls, aber wenn es fertig ist, ist das Tif16 selbst, obsolet. Das fliegt dann raus.

Irgendwann muß es fertig sein. Sonst fummelt man noch 2019 schon wieder an RAWs die man 2005 gemacht hat

betazoid schrieb:

Noch zum PS und jpf: Das Problem ist, dass insbesondere Affinity, mit dem ich in letzter Zeit kokettiere, die von PS erzeugten Dateien nicht öffnet.

Zum Vergrößern anklicken....

Und hast du es mal mit umbenennen probiert? (Wie gesagt, ich vermute
eigentlich, dass dein PS die Dateien zwar mit der Endung jpf versieht, dass
der Inhalt aber jp2-konform ist). (*2)

Nachtrag: Ich habe es eben mit einer Trail-Version von Affinity-Photo
probiert, und es lädt das Jpf-File von PSE nicht ... weder im Original,
noch umbenannt. (Im Original wird es im Öffnen Dialog erst gar nicht angezeigt,
umbenannt erscheint es, das Öffnen schlägt aber mit einem Fehler-Popup fehlt
... im Popup steht, dass es ein nicht unterstützter Dateityp wäre.

*2: Und hier vermute ich offensichtlich falsch ...
Im Header einer Jp2-Datei steht u.a "ftypjp2....jp2....jp2h...ihdr"
Im Header einer Jpf-Datei steht hier "ftypjp2....jp2... jpxbjpx..."
Im dritten String scheint sich der Hinweis auf die Extensions (Part-2)
zu befinden.

Dann liegt aber das Problem eigentlich in der Implementierung von Affinity ...
den, die könnten ja auch die Erweiterungen des J2K Standards unterstützen.

PGP schrieb:

@RainerT
Das ist richtig bzw. mir insofern bekannt. Wenn man ein 8MB Tif8/Lzw fest auf 100 80KB pressen will, sieht das mit Jpeg2000 merklich besser aus als mit Jpeg.
Bleibt nur die Frage was man damit anfangen will.

Der Vergleich beim Aufwand von Coding/Decoding ändert sich dadurch aber nur unwesentlich. Andererseits lese ich hier zwischendurch was von losless und 16bit, hab das also eher aus der Sicht einer möglichst hohen Qualität betrachtet

Wenn man ggf. wie betazoid hin und her schaufelt (so wie ich das verstehe), eignet sich dafür Tif16 weiterhin bestens.
Das macht zwar knappe 60MB pro 10MP (?), das ist aber für mich nur ein Zwischenergebnis, was man da rumreicht. Ich mache das zwischen Optics und Lightroom ebenfalls, aber wenn es fertig ist, ist das Tif16 selbst, obsolet. Das fliegt dann raus.

Irgendwann muß es fertig sein. Sonst fummelt man noch 2019 schon wieder an RAWs die man 2005 gemacht hat

Zum Vergrößern anklicken....

Naja, das ist für mich leider nicht so. Ich habe einerseits ein Bedürfnis nach lossless, das deutlich kleiner ist ein ein tiff, und Exif enthält, das ist mir auch sehr wichtig. Und 16 Bit natürlich. Andererseits würds mich nicht stören wenn die Bildqualität bei JPEG beim Komprimieren irgendwann nicht so stark einbrechen würde, aber da ist JPEG2000 nicht sooo viel besser.

War eigentlich schon von 16-Bit-JPEG die Rede hier? Gibt es sowas?

Und was mir noch einfällt: Wie wird eigentlich das PSD-Dateiformat komprimiert? Ist das nicht besser als TIFF?
Also bei Photoline bin ich mir ziemlich sicher, dass die Komprimierung auf PNG beruht, aber gleichzeitig bin ich mich auch recht sicher, dass EXIF erhalten bleiben.
Was gäbe es da noch alles für Dateiformate? PDF lossless ist ja nicht wirklich kleiner, oder (obwohl es das, wie bereits erwähnt wurde, auch mit JPEG2000 gibt)?
Corel Photo Paint (ist ja uuuralt)?

betazoid schrieb:

War eigentlich schon von 16-Bit-JPEG die Rede hier? Gibt es sowas?

Zum Vergrößern anklicken....

Ich glaube nicht ... aber zumindest 12bit sind wohl von der Norm her
schon vorgesehen ...

https://de.wikipedia.org/wiki/JPEG

... aber andererseits ist es eine Sache, was eine Norm schreibt,
und eine andere wie sie typischerweise implementiert wird.

Viele Jpeg-Implementierungen verwenden eben nur die Variante mit 8bit
Farbtiefe. (Daher auch der Nebesatz im Wiki-Artikel ... "von denen nur die
farbig unterlegten gebräuchlich sind").

betazoid schrieb:

..aber bei 75%er JPEG Qualität leidet die Bildqualität schon sehr...

Zum Vergrößern anklicken....

ich lade die bilder manchmal sogar mit 45-50% hoch (website), da der unterschied zu 100% so gut wie unsichtbar ist. maximal aber 60%.
75% sind luxus

betazoid schrieb:

Naja, das ist für mich leider nicht so. Ich habe einerseits ein Bedürfnis nach lossless, das deutlich kleiner ist ein ein tiff, und Exif enthält, das ist mir auch sehr wichtig. Und 16 Bit natürlich.

Zum Vergrößern anklicken....

Ich hab das mit dem Fallbeispiel irgendwie total verpennt (?)

betazoid schrieb:

War eigentlich schon von 16-Bit-JPEG die Rede hier? Gibt es sowas?

Zum Vergrößern anklicken....

Mit JPEG XR (eigener Container: *.jxr) oder JPEG XT (ist eher eine Ab-/Aufwärtskompatible Erweiterung) ist das prinzipiell schon möglich...

betazoid schrieb:

Und was mir noch einfällt: Wie wird eigentlich das PSD-Dateiformat komprimiert? Ist das nicht besser als TIFF?

Zum Vergrößern anklicken....

Soweit ich weiß nutzt es RLE:
https://en.wikipedia.org/wiki/Run-length_encoding

TIFF nutzt zur verlustlosen Kompression üblicherweise LZW...optional möglich wäre als Verlustfreies Verfahren aber auch, da TIFF halt recht flexibel ist, DEFLATE (wie bei PNG...aber selten umgesetzt) oder ebenfalls RLE (extrem selten).

Dürfte wohl vom Inhalt und Nutzungszweck abhängen welches Verfahren (LZW/Deflate/RLE) besser ist!

betazoid schrieb:

Und was mir noch einfällt: Wie wird eigentlich das PSD-Dateiformat komprimiert? Ist das nicht besser als TIFF?

Zum Vergrößern anklicken....

TIFF ist kein Codec(!), sondern ein Container. Und zwar ein ziemlich komplexer Container. Der enthaltene Code KANN beispielsweise ein unkomprimiertes CMYK Format sein, es KANN (und jetzt wird es nämlich unübersichtlich) auch ein verlustbehaftetes Jpeg Format sein.

Auf dieser Basis machen die hier genannten Vergleiche zu TIFF überhaupt keinen Sinn. Nur TIFF sagt überhaupt nichts darüber hinaus, was letztendlich gespeichert wird, wie groß es ist, wieviel Bits unterstützt werden, ob es verlustfrei ist und und und. Es ist wie MKV (Matroska Video) ein Container.

Du müßtest schon ein konkretes Format des eingebetten Codecs nennen, den Du mit TIFF abspeichern und vergleichen willst. Nur sieht man das leider nicht an der Dateierweiterung *.tif. Mit dem sog. "Compression Tag" mit Wert 8798 wird in TIFF übrigens JPG2000 abgespeichert. Im Wiki https://en.wikipedia.org/wiki/TIFF findet man eine Tabelle, welche Compressionen unterstützt werden. Die volle TIFF Spezifikation ist ein Wälzer: https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf

betazoid schrieb:

Ist die Endung jp2 oder jpf/jpx?

Zum Vergrößern anklicken....

Jp2. Die Bildvorschau auf dem Mac kann es auch lesen.