Neue Testversion 20.90b4

[Martin Huber]

toll das die Arbeitsebenenauswahl in der Beta mehrzeilig ausklappt. Kommt das irgendwann in die offizielle Version?

Wenn es keine Proteste oder Fehlermeldungen gibt, die die Mehrspaltigkeit in Frage stellen, kommt das sicher mal in die offizielle Version.

Martin

[Ralf]

toll das die Arbeitsebenenauswahl in der Beta mehrzeilig ausklappt. Kommt das irgendwann in die offizielle Version?

Wenn es keine Proteste oder Fehlermeldungen gibt, die die Mehrspaltigkeit in Frage stellen, kommt das sicher mal in die offizielle Version.

Das würde mir gefallen.

Gruß
Ralf

[Hoogo]

"Effekte > Verzerren > Umrissverzerrung" zeigt die Beleuchtungs-Einstellungen immer in Dunkel an.

[Hoogo]

DAs Verzerren liefert bei mir einen komisch rot/Weissen Hintergrund, der beim Neuzeichnen teilweise verschwindet.

[Hoogo]

Kein Bug, nur was Interessantes zum drüber Grübeln, ein überraschendes Ergebnis des Subsamplings
Da kam mir so der Gedanke, ob das besser würde, wenn man beim Verringern der Auflösung die 4 Punkte im Verhältnis Ihrer Sättigung miteinander verrechnen würde?

[Gerhard Huber]

DAs Verzerren liefert bei mir einen komisch rot/Weissen Hintergrund, der beim Neuzeichnen teilweise verschwindet.

Das ist die Rechtschreibkorrektur. Du hast einen Fehler in deinem Wort

[Gerhard Huber]

"Effekte > Verzerren > Umrissverzerrung" zeigt die Beleuchtungs-Einstellungen immer in Dunkel an.

Ich sehe mir das an.

[Martin Huber]

Kein Bug, nur was Interessantes zum drüber Grübeln, ein überraschendes Ergebnis des Subsamplings
Da kam mir so der Gedanke, ob das besser würde, wenn man beim Verringern der Auflösung die 4 Punkte im Verhältnis Ihrer Sättigung miteinander verrechnen würde?

Dir "gefällt" das erzeugte JPEG nicht? Die JPEGs werden über eine Standardbibliothek erzeugt und wir haben da kaum Einfluss darauf. Ich bin mir auch nicht sicher, ob man da überhaupt was ändern könnte, ohne dass andere Programme die erzeugten JPEGs dann falsch anzeigen.
Mit "Erhöhte Qualität" tritt der Effekt natürlich nicht mehr auf, weil es dann kein Subsampling mehr gibt.

Martin

[bkh]

Kein Bug, nur was Interessantes zum drüber Grübeln, ein überraschendes Ergebnis des Subsamplings
Da kam mir so der Gedanke, ob das besser würde, wenn man beim Verringern der Auflösung die 4 Punkte im Verhältnis Ihrer Sättigung miteinander verrechnen würde?

Das Problem ist (wieder einmal), dass Mittelwerte ohne Berücksichtigung der Tonwertkurve berechnet werden. Wenn du den Gauss'schen Weichzeichner nimmst, hast du den gleichen Effekt. Wenn du nach 16 bit linear konvertierst und dann weichzeichnest, verschwindet der Effekt. (Für JPEG könnte man im Prinzip im linearen Raum nach YCrCb konvertieren, bei Cr und Cb weichzeichnen und dann nach RGB mit Tonwertkurve zurückwandeln, um das Problem zu vermeiden.)

Für die Praxis sollte das aber kein Problem sein, da hohe Intensitäten bei hohen Frequenzen bei Fotos usw. nicht vorkommen.

L.G.

Burkhard.

[Hoogo]

Das Problem ist (wieder einmal), dass Mittelwerte ohne Berücksichtigung der Tonwertkurve berechnet werden. Wenn du den Gauss'schen Weichzeichner nimmst, hast du den gleichen Effekt. Wenn du nach 16 bit linear konvertierst und dann weichzeichnest, verschwindet der Effekt.

Oh ja, Gamma hab ich nicht mehr wirklich im Blick gehabt. Allerdings vermute ich, dass das hier nebensächlich ist. Diese Pixel in extremen Schwarz-Rot-Weiss würde in YCrCb immer die gleichen Werte ergebe, egal, ob das Gamma nun 1 oder 2.2 ist.
Ist auch blöd, dass ich hier das böse Testmuster fürs Gamma genommen habe. Mir geht es aber nicht um den Eindruck, sondern um die echten Zahlenwerte, die die Pixel haben.
------
Ich hab da mal ein bisschen mit Bordmitteln experimentiert. Das Ergebnis überrascht mich, bin mir aber nicht sicher, ob ich den Prozess wirklich 100% nachgestellt habe. In meinen Voreinstellungen des Kanalmixers habe ich CrYCb drin, muss ich irgendwann mal erstellt haben.

Schwarz wird zu 128/0/128, üblichere Reihenfolge und "Schreibweise" 0/+0/+0.
Rot wird 255/76/84 bzw. 76/+127/-44
Weiss wird 128/255/128 bzw. 255/+0/+0

Beim simpelsten Subsampling wird nun der Durchschnitt von 4 Pixeln Cr und Cb gebildet, wobei die Hälfte der Punkte farblos ist. Macht CrCb +63/-22.
Bei einem nach "Farbigkeit" gewichteten "Durchschnitt" würden die farblosen Punkte ignoriert, CrCb wären +127/-44

Unerwaretes Jpg.png

1) Das Ursprungsbild aus reinem Schwarz-Rot-Weiss
2) Echte Jpg-Kompression
3) Aus dem Original nach CrYCb umgerechnet. Die 2 Balken haben die von Hand berechneten CrCb-Werte
4) Cr und Cb weichgezeichnet. Sehr subtil, erkennt man hier praktisch nur beim Reinzoomen.
5) nach RGB zurückgerechnet.
6) Ein Ausschnitt zum schöneren Vergleich zwischen Original und Jpg.

Die roten Pixel sind wie gewünscht wieder knallrot geworden.
Das bunte Schwarz, dass außerhalb des RGB-Raums ist, ist aber unerwartet Hell geworden. Weiss ebenso sehr dunkel.
In 32Bit sind die RGB-Werte für das bunte Schwarz 176/-76/-77.
Der Kanalmixer setzt die falschen Werte einfach auf 0, und ich vermute, Jpg wird bei so unmöglichen Farben das Gleiche tun - weiss ich aber nicht!

Ich muss echt mal wieder ans Programmieren kommen

[Hoogo]

Beim rumbasteln ist mir diese etwas kaputte Werkzeugleiste aufgefallen.
Die genauen Schritte bekomme ich jetzt nicht mehr hin, aber mit Strg+C, Strg+V bekomme ich sehr ähnliches hin. Da wird dann wohl das Fensterchen für eine Breite von 4 Werkzeugen eingerichtet, nur wird das gebundene Fensterchen in der Höhe nicht größer.

[bkh]

Das Problem ist (wieder einmal), dass Mittelwerte ohne Berücksichtigung der Tonwertkurve berechnet werden. Wenn du den Gauss'schen Weichzeichner nimmst, hast du den gleichen Effekt. Wenn du nach 16 bit linear konvertierst und dann weichzeichnest, verschwindet der Effekt.

Oh ja, Gamma hab ich nicht mehr wirklich im Blick gehabt. Allerdings vermute ich, dass das hier nebensächlich ist. Diese Pixel in extremen Schwarz-Rot-Weiss würde in YCrCb immer die gleichen Werte ergebe, egal, ob das Gamma nun 1 oder 2.2 ist.
Ist auch blöd, dass ich hier das böse Testmuster fürs Gamma genommen habe. Mir geht es aber nicht um den Eindruck, sondern um die echten Zahlenwerte, die die Pixel haben.

Sorry, aber dann verstehe ich dein Problem nicht. Das Problem der Tonwertkurve bei der Durchschnittsbildung hast du im YCrCb-Farbraum genauso (oder noch schlimmer, wegen der Differenzen). Bei 4:2:2 subsampling würde ich nicht erwarten, dass die einzelnen Farb-Pixelwerte sinnvoll sind, sondern eher, dass der Gesamtfarbeindruck erhalten bleibt. Die Durchschnittsfarbe des Quadrats des JPEG oben links stimmt in etwa, die anderen (Durchscnitts-)Farben weichen stark ab, insbesondere unten links, da sehe ich das Hauptproblem.

Möglich, dass man die Durchschnittsbildung so variieren könnte, dass für das konkrete Beispiel ein etwas besseres Ergebnis herauskommt, aber dann gibt es mit Sicherheit andere Beispiele, bei denen das Ergebnis schlechter würde.

L.G.

Burkhard.

[Hoogo]

Oh ja, Gamma hab ich nicht mehr wirklich im Blick gehabt. Allerdings vermute ich, dass das hier nebensächlich ist. Diese Pixel in extremen Schwarz-Rot-Weiss würde in YCrCb immer die gleichen Werte ergebe, egal, ob das Gamma nun 1 oder 2.2 ist.
Ist auch blöd, dass ich hier das böse Testmuster fürs Gamma genommen habe. Mir geht es aber nicht um den Eindruck, sondern um die echten Zahlenwerte, die die Pixel haben.

Sorry, aber dann verstehe ich dein Problem nicht.

Mein "Problem" ist der Verlust an Farbigkeit, der im konkreten Fall rechnerisch nachvollziehbar ist, aber imho unnötig gewesen wäre. Hier wäre es OK gewesen, wenn mehr von der roten Farbigkeit ins Schwarze oder weiße geblutet wäre, die ja bei einer Priorität auf Helligkeit doch wieder Sättigung verloren hätten.

Das Problem der Tonwertkurve bei der Durchschnittsbildung hast du im YCrCb-Farbraum genauso (oder noch schlimmer, wegen der Differenzen).

Jein.
Bei den gewählten extremen Schwarz-Rot-Weiss spielt es keine Rolle.
Bei echten Bildern könnten sich andere Zahlen ergeben, wobei aber Codierer und Decodierer diese Umrechnung berücksichtigen müssten. Von Rundungsfehlern abgesehen müsste dann glaub ich doch wieder ziemlich das Gleiche rauskommen.

Bei 4:2:2 subsampling würde ich nicht erwarten, dass die einzelnen Farb-Pixelwerte sinnvoll sind, sondern eher, dass der Gesamtfarbeindruck erhalten bleibt. Die Durchschnittsfarbe des Quadrats des JPEG oben links stimmt in etwa, die anderen (Durchschnitts-)Farben weichen stark ab, insbesondere unten links, da sehe ich das Hauptproblem.

Die oberen beiden der 4 Quadrate sind doch deutlich farbloser als die beiden Originale untendrunter?

Hab in der libjpeg, jdcolor.c, die wohl übliche Umrechnung YCrCb zu RGB gefunden:
y = GETJSAMPLE(inptr0[col]);
cb = GETJSAMPLE(inptr1[col]);
cr = GETJSAMPLE(inptr2[col]);
/* Range-limiting is essential due to noise introduced by DCT losses. */
outptr[RGB_RED] = range_limit[y + Crrtab[cr]];
...

range_limit clippt nur. Es passiert nichts komplizierteres, um so komische RGB-Werte wie 179/-76/-77 oder 434/179/177 wieder zu Schwarz oder Weiß zurückzusetzen. Damit wäre der Fall wohl erledigt.

[bkh]

Sorry, aber dann verstehe ich dein Problem nicht.

Mein "Problem" ist der Verlust an Farbigkeit, der im konkreten Fall rechnerisch nachvollziehbar ist, aber imho unnötig gewesen wäre. Hier wäre es OK gewesen, wenn mehr von der roten Farbigkeit ins Schwarze oder weiße geblutet wäre, die ja bei einer Priorität auf Helligkeit doch wieder Sättigung verloren hätten.

OK, dann sehen wir wohl doch das gleiche Problem.

Das Problem der Tonwertkurve bei der Durchschnittsbildung hast du im YCrCb-Farbraum genauso (oder noch schlimmer, wegen der Differenzen).

Jein.
Bei den gewählten extremen Schwarz-Rot-Weiss spielt es keine Rolle.

Doch, genau das ist das Problem – auf der linken Seite fast ausschließlich – in dem Fall pasiert das bei der Mittelwertbildung im Cr-Kanal. Dort ist der Einfluss des Clipping sehr gering und der Effekt entspricht fast dem der Weichzeichnung ohne Berücksichtigung der Tonwertkurve.

Auf der rechten Seite spielt zusätzlich das starke Clipping eine Rolle, aber auch hier verändert sich das Feld schon durch die reine Weichzeichung/Subsampling ohne Tonwertberücksichtigung stark.

Wie schon gesagt: ohne den zusätzlichen Effekt durch das Clipping wäre das Resultat der JPEG-Kompression, aus einer Entfernung betrachtet, wo man die einzelnen Pixel nicht mehr unterscheiden kann, der gleiche wie bei einer reinen Weichzeichnung ohne Tonwertberücksichtigung.

Hier noch mal eine Variation des Beispiels, wo Clipping keine Rolle spielt (Farbwerte des Originals zwischen 32 und 223) und der Effekt trotzdem auftritt:

Unerwartetes Jpg-2.png

L.G.

Burkhard.

[bkh]

Hier zum Vergleich nochmal die gleiche Transformation, aber mit linearem Farbraum. Das Schwarz ist so flau, damit es beim Umrechnen kein Clipping gibt. Wenn die Tonwertkurve des Monitors korrekt eingestellt ist, sollte man zwischen oben (weichgezeichnete Cr- und Cb-Kanäle) und unten keinen Unterschied geben.

Unerwartetes Jpg-2-linear.png

L.G.

Burkhard.