jpg-Illuminator: Bugs und Verbesserungs-Vorschläge

  • @betram:


    Ich bin kein Programmierer (zumindest nicht mehr als notwendig...), insofern ahbe ich da wenig Ahnung, was eine 16Bit Unterstützung oder andere Dateiformate für euer Tool bedeuten würden. :)


    An automatisierbaren "Kaschierungen" fällt mir zuerst einmal künstliches monochromes Korn ein, das lässt die Sprünge etwas weniger stark auffallen (und tut z.B. auch stark entrauschten Bildern gut, die dann etwas weniger steril und weich wirken, oder auch etwas unscharfen Bilder, da es dem Auge Details vorgaukelt, die nicht da sind).
    Man könnte auch versuchen einfarbige Flächen (wo die Abrisse besonders auffallen) von Schärfungsalgorithmen auszunehmen oder eher hohe Schwellenwerte beim Schärfen zu verwenden, um so die Abrisse zumindets nicht unnötig zu betonen.
    Automatisierte Weichzeichner zum Entfernen stelle ich mir schwer vor, da die Wecihzeichnung recht heftig sein muss und - wenn etwas ungenau angewendet - auch andere Details zerstört.

    • Offizieller Beitrag

    Die Idee mit dem Korn wäre vielleicht wirklich ein denkbarer Weg. Ausserdem könnte man steuerbares Korn gut bei der s/w-Wandlung gebrauchen.


    Aber.


    Schöner wäre es ohne eine künstliche Verschlechterung. Ich stelle mir weiterhin eine Weichzeichnung vor, die (mit regelbarem Schwellwert) nur in detailarmen Bereichen angreift, die sich dort nur die 'Kanten' der Tonwertabrisse schnappt und mit einstellbarem Radius weichzeichnet und die womöglich sogar Details schont, die in die Weichzeichnungsradien geraten, sofern diese Details Tonwertunterschiede aufweisen, die außerhalb des Schwellwerts liegen. So etwa.

    • Offizieller Beitrag

    PS: Den Schaden der oben geschilderten 'selektiven Weichzeichnung' auf andere Bildteile könnte man doch vielleicht begrenzen, indem man sie nur auf Bildelemente anwendet, die gegenüber Ihrem 'Nachbarn' durch die eingestellten Bearbeitungswerte fürs Bild eine gewisse 'Mindestspreizung' erfahren haben.


    Anders ausgedrückt: Im Gegensatz zu anderen Programmen hat der Illuminator doch den Vorteil, jederzeit das Ausgangsbild mit dem eingestellten Ergebnisbild vergleichen zu können. Er 'weiss' also, wo Tonwerte, die vorher sehr eng beieinander lagen durch die Bearbeitung besonders breit aufgespreizt werden. Nur dort muss eine solche Korrektur angreifen.


    Dann noch die genannte Schutzfunktion für alle Details , die in die Radien geraten aber im Ursprungsbild schon sauber getrennt waren...


    Aber wahrscheinlich stelle ich mir das wieder zu leicht vor.

  • Bei dem Bild hier aus dem "Pimp it"-Thread habe ich mal durch Kontrastanhebung in den Kanäle hübsche Tonwertabrisse herbeigeführt:



    Wenn man das dann in den einzelnen Kanälen ansieht und jeweils mit einem selektiven Weichzeichner (PS: "Matter machen") entfernt, dann erwischt man leider auch Details anderswo im Bild, die keine Tonwertabrisse sind:


    Mit dem künstlichen Korn ließ sich das noch etwas kaschieren, aber die Bäume im Hintergrund ahben doch ganz massiv an Zeichnung verloren:



    Ist besser als das Bild mit Abrissen, aber hübsch ist es so eher nicht.
    Die Frage ist auch, ob eine Automatik ohne weiteres die Werte für die Weichzeichnung so passend einstellen könnte.



    Ein Versuch 2 Hochpassebenen von vor und nach der Kontrasterhöhung miteinander zu verrechnen hat zumindets auf die Schnelle nur deutlich schlechter funktioniert.

    • Offizieller Beitrag
    Zitat von "Flash"

    An automatisierbaren "Kaschierungen" fällt mir zuerst einmal künstliches monochromes Korn ein, das lässt die Sprünge etwas weniger stark auffallen (und tut z.B. auch stark entrauschten Bildern gut, die dann etwas weniger steril und weich wirken, oder auch etwas unscharfen Bilder, da es dem Auge Details vorgaukelt, die nicht da sind).

    Ja, damit haben wir auch schon experimentiert. Weiß jemand, ob der Unterschied zwischen Rauschen und "Korn" eine Rolle spielt? Bisher haben wir nur reines (weißes) Zufallsrauschen benutzt.



    Zitat von "Flash"

    Man könnte auch versuchen einfarbige Flächen (wo die Abrisse besonders auffallen) von Schärfungsalgorithmen auszunehmen oder eher hohe Schwellenwerte beim Schärfen zu verwenden, um so die Abrisse zumindets nicht unnötig zu betonen.


    Ja, aber das Schärfen verstärkt das Rauschen, weniger die Abrisse. Es geht uns in erster Linie nicht um eine Rauschunterdrückung, sondern wir wollen die Abrisse kaschieren. Das Rauschen darf ruhig drin blieben.


    Zitat von "Flash"

    Automatisierte Weichzeichner zum Entfernen stelle ich mir schwer vor, da die Wecihzeichnung recht heftig sein muss und - wenn etwas ungenau angewendet - auch andere Details zerstört.

    Genau das ist der springende Punkt. Wobei wir ja im wesentlichen das Rauschen gar nicht entfernen wollen, diesen Vorteil versuchen wir auszunutzen.



    Zitat von "le spationaute"

    Ich stelle mir weiterhin eine Weichzeichnung vor, die (mit regelbarem Schwellwert) nur in detailarmen Bereichen angreift, die sich dort nur die 'Kanten' der Tonwertabrisse schnappt und mit einstellbarem Radius weichzeichnet und die womöglich sogar Details schont, die in die Weichzeichnungsradien geraten, sofern diese Details Tonwertunterschiede aufweisen, die außerhalb des Schwellwerts liegen.

    Im Prinzip ist es das, was wir versuchen.


    Zitat von "le spationaute"

    Den Schaden der oben geschilderten 'selektiven Weichzeichnung' auf andere Bildteile könnte man doch vielleicht begrenzen, indem man sie nur auf Bildelemente anwendet, die gegenüber Ihrem 'Nachbarn' durch die eingestellten Bearbeitungswerte fürs Bild eine gewisse 'Mindestspreizung' erfahren haben.


    Das wäre zweifellos optimal, aber es ist auch schwer zu implementieren. Original und Endergebnis zu vergleichen genügt leider nicht, man muss auch lokal die Gradationen der Kanäle an jedem Bildpunkt berechnen. D.h. man müsste leicht abweichende Testbilder durchrechnen und sich die Auswirkung auf das Endergebnis betrachten und dann die Glättungsparameter dynamisch anpassen. Das wäre wie gesagt sehr viel Aufwand und würde auch sehr viel Rechenzeit kosten.
    Ich bin mir auch nicht sicher, ob das wirklich eine entscheidende Verbesserung bewirken würde, denn detailreiche und detailarme Bildbereiche können trotz ähnlicher Farbe und Helligkeit nebeneinander existieren und müssen unterschiedlich behandelt werden.


    Jedenfalls sind wir an dem Thema dran und wir haben auch schon Teilerfolge erzielt - allerdings hängt es vom Bildmaterial ab und unser Verfahren skaliert nicht optimal mit der Bildgröße. Flashs Bild könnte z.B. so aus dem ji kommen, nur funktioniert der Algorithmus in der Originalgröße noch nicht genauso gut wie in der hier gezeigten Verkleinerung:

  • ... Ich mal wieder ;)


    Für "ganz normale Bilder" benutze ich inzwischen eigentlich nur noch ein Tool... den JI; eigentlich... denn der letzte Schritt findet immer noch woanders statt - die gezielte Reduzierung der fertigen Datei auf eine bestimmte Dateigröße (fc -> max. 400kB, dft -> max. 250kB, ...).
    Im JI ist das für mich immer ein "try-and-error" Spielchen und außerdem hab ich die JPG Komprimierung lieber auf 100% stehen, sonst vergesse ich das mal wieder und speichere danach alles in einer "falschen" Komprimierung.


    Hab ich wieder einmal eine kleine Einstellung übersehen? Oder wenn nicht - kann man das vielleicht dem JI beibringen? :D

    EBV :daumenhoch:


    Sony α1 - Sony 200-600mm G OSS - Sony FE 100-400mm GM OSS - Sony FE 1.4x Telekonverter - Sony FE 16-35mm ZA - Sony FE 24-105mm G - Sony FE 24-240mm OSS - Sony FE 85mm f/1.8 - Samyang 12mm f/2.8 Fisheye - Tamron 90mm USD Makro

    • Offizieller Beitrag
    Zitat

    Holger: ... benutze ich inzwischen eigentlich nur noch ein Tool...


    :thumbup: Das freut uns!


    Zu deinem Vorschlag, die Dateigröße vorauszubestimmen:
    Diese Funktion vermissen wir schon lange. Uns ist aber noch keine einfache Lösung eingefallen. Das hängt mit folgenden Überlegungen zusammen:
    JI arbeitet standardmäßig im Quickmodus. Das eigentliche Bild wird erst nach dem Befehl "speichern" im Hintergrund aus dem Original berechnet und danach komprimiert und gespeichert. Währenddessen arbeitet der User schon am nächsten Bild. Erst wenn das Bild komprimiert ist, lässt sich feststellen, wie viele kb es haben wird. (Zumindest kennen wir kein Verfahren, das vorher zu ermitteln.)
    Welche "work-arounds" wären denkbar?
    Ein extra Menüpunkt "speichern mit xx kb".
    Der User müsste zunächst warten bis das Bild berechnet und mit der aktuellen Qualität komprimiert ist. Die Dateigröße bekäme er dann angezeigt und könnte danach die Qualität verändern ...
    Oder eine Art Automatik. Der User gibt die Zielgröße an. JI berechnet im Hintergrund das Bild, komprimiert es, ändert die Qualität, komprimiert es, ändert die Qualität ..., bis die Zielgröße angenähert ist.


    In der Regel ist es ja so, dass dieses Feature nur bei kleinen Bildgrößen fürs Internet gebraucht wird. Insofern wäre die Wartezeit nicht das Problem. Also vielleicht so ein Menüpunkt "speichern mit xx kb"? Oder kombinieren im Menüpunkt "speichern fürs Web"?

  • Zitat von "bertram"

    Welche "work-arounds" wären denkbar?
    Ein extra Menüpunkt "speichern mit xx kb".

    Würde mir reichen, wobei das xx einstellbar (z.B. Pop-Up oder Optionen) sein muss.


    Zitat

    Der User müsste zunächst warten bis das Bild berechnet und mit der aktuellen Qualität komprimiert ist. Die Dateigröße bekäme er dann angezeigt und könnte danach die Qualität verändern ...

    Eher schlecht, das ist ja im Prinzip der Weg den ich gerade gehe, außer das ich die Dateigröße auf der Platte im Explorer nachschlagen muss...


    Zitat

    Oder eine Art Automatik. Der User gibt die Zielgröße an. JI berechnet im Hintergrund das Bild, komprimiert es, ändert die Qualität, komprimiert es, ändert die Qualität ..., bis die Zielgröße angenähert ist.

    Das klingt zumindest nach einem gangbaren Weg - optimal ist es sicher nicht (aus Programmierer-Sicht), aber als Lösung für den Benutzer mit Sicherheit :thumbup:


    Zitat

    In der Regel ist es ja so, dass dieses Feature nur bei kleinen Bildgrößen fürs Internet gebraucht wird. Insofern wäre die Wartezeit nicht das Problem. Also vielleicht so ein Menüpunkt "speichern mit xx kb"? Oder kombinieren im Menüpunkt "speichern fürs Web"?


    Stimmt - es betrifft eigentlich immer nur kleine Bilder bei denen das Speichern sowieso nicht allzu lange dauert. Mir am liebsten wäre es an beiden Stellen, dann würde ich mir auch noch das optionale Löschen der EXIFs in einem weiteren Tool los. :mrgreen:

    EBV :daumenhoch:


    Sony α1 - Sony 200-600mm G OSS - Sony FE 100-400mm GM OSS - Sony FE 1.4x Telekonverter - Sony FE 16-35mm ZA - Sony FE 24-105mm G - Sony FE 24-240mm OSS - Sony FE 85mm f/1.8 - Samyang 12mm f/2.8 Fisheye - Tamron 90mm USD Makro

    Einmal editiert, zuletzt von HoSt ()

  • IrfanView hat die Option, Bilder mit einer bestimmten Dateigröße zu speichern. Da ich dieses Feature aber für genauso fragwürdig halte wie Video- oder Audio-Datenreduktion mit fester Bitrate, habe ich es noch nie verwendet. GIMP zeigt die resultierende Dateigröße an, wenn man die Vorschau aktiviert. Dann wird nach jeder Änderung der jpg-Qualität das Bild neu berechnet.
    Vielleicht wäre die GIMP-Lösung am Einfachsten zu realisieren?


    Grüßle hg

  • So ähnlich macht es PhotoImpact (den ich im übrigen genau dafür als Tool nach dem JI verwende) auch... da kann man schön sehen, wann es "paßt":

    Bilder

    EBV :daumenhoch:


    Sony α1 - Sony 200-600mm G OSS - Sony FE 100-400mm GM OSS - Sony FE 1.4x Telekonverter - Sony FE 16-35mm ZA - Sony FE 24-105mm G - Sony FE 24-240mm OSS - Sony FE 85mm f/1.8 - Samyang 12mm f/2.8 Fisheye - Tamron 90mm USD Makro

  • Ich verwende in XnView das Plugin RIOT, das gibt es auch Standalone, Freeware. Es zeigt quasi in Echtzeit die Auswirkung der Kompression, man kann also sehr schön sehen ab welchem Kompressionsgrad Artefakte sichtbar werden. Das Tool hat auch einen 'Compress to File Size' Button für die hier gewünschte Funktion.


    Falls das unsere Entwickler nicht kennen - schaut doch mal, vielleicht gibt das eine Anregung für unser Illu...

  • Zitat von "Samedate"

    Ich verwende in XnView das Plugin RIOT, das gibt es auch Standalone, Freeware. Es zeigt quasi in Echtzeit die Auswirkung der Kompression, ....


    Quasi Echtzeit kann nur bei kleinen Bildern funktionieren, weil ja bei jeder Änderung eine Neuberechnung erfolgen muß...


    Der andere Weg wäre, wie Bertram schrieb, das Ergebnis in mehreren Iterationen an die Wunschgröße anzunähern...


    Aber gibt es wirklich Anwendungsfälle, die zwingend eine feste Dateigröße verlangen?

  • Zitat von "bertram"

    Dass es Programme gibt, die das können, ist schon klar. Die Frage ist, wie funktioniert das? Mit diesem Problem haben wir uns noch nicht befasst. Und aus dem Handgelenk können wir die Lösung nicht schütteln. :(


    Das Funktioniert nur über ausprobieren.
    Am einfachsten das Bild in einen Stream komprimieren die Size ermitteln und falls die Wunschgröße noch nicht erreicht ist mit einem kleineren QF das ganze wiederholen bis zum Schwellenwert von, sagen wir mal 25.

  • Zitat von "Sunhillow"

    Aber gibt es wirklich Anwendungsfälle, die zwingend eine feste Dateigröße verlangen?

    Keine feste (das wäre ja sowieso nicht machbar), aber ein maximale Dateigröße ist bei den meisten Online-Galerien ja vorgegeben, z.B. hier die max. 250kB oder in der fc 400kB.

    EBV :daumenhoch:


    Sony α1 - Sony 200-600mm G OSS - Sony FE 100-400mm GM OSS - Sony FE 1.4x Telekonverter - Sony FE 16-35mm ZA - Sony FE 24-105mm G - Sony FE 24-240mm OSS - Sony FE 85mm f/1.8 - Samyang 12mm f/2.8 Fisheye - Tamron 90mm USD Makro

  • Wenn man Bilder aus dem Internet herunterladen möchte, diese aber zunächst nicht speichern will, so bietet sich folgende Möglichkeit an:


    Mittels 'Bild senden...' aus dem Kontextmenü auf das betreffende Bild wird dieses in ein leeres eMail eingefügt. Mittels Drag&Drop kann man dann das Bild auf ein Bildanzeige-Fenster, z.B. IrfanView ziehen, wodurch dieses kommentarlos angezeigt wird.


    Bis mindestens v4.1.4.1 ging das mit JI ebenso problemlos. Danach, bis mindestens v4.2.7.8, kam dann immer eine längere Warnung, die man jedoch ignorieren konnte, das das Bild trotzdem geladen wurde. Seit mindestens v4.3.0.1 stürzt JI unter Anzeige einer Fehlermeldung ab:


    'Anwendungsfehler: Exception EInvalidPointer in Modul jpgIlluminator.exe bei 000040DD. Ungültige Zeigeroperation.'.


    Was ist da in 2 Stufen anders geworden und lässt sich das Rad wieder zurückdrehen?


    Windows 7 64 Bit

    • Offizieller Beitrag

    Hm, da bin ich zunächst mal ratlos. Für diesen Zweck wurde in ji nie etwas programmiert. Ich selber benutze dafür die Zwischenablage und in ji "Bild > einfügen". Kann es sein, dass das Problem auf Seiten des eMail-Klient liegt? Denn mit meinem kann ich auf die geschilderte Art auch in IrfanView kein Bild einfügen und in ji ergibt sich gar keine Reaktion.

  • Ein Bild verkleinern kann man mittels 'Bild verkleinern oder vergrößern auf:', indem man den Wert für die lange Seite aus einer Liste auswählt. Will man dann den Wert durch Anklicken der im Menü weit unten stehenden Schaltfläche 'Größe ändern' bestätigen, stellt man fest, dass es direkt über dieser Schaltfläche eine aktivierte Checkbox 'Seitenverhältnis beibehalten' gibt.


    Aber oh je, das wollte man doch gar nicht! Also Haken raus!


    Aber oh je, die kurze Seite ist ja auch verändert! Wie war noch der Ausgangswert?


    Dumm, weiss man nicht genau. Also auf 'abbrechen' klicken und das Ganze von neuem, jetzt aber zuerst nach unten ans Ende des Menüs und den Haken herausnehmen und dann im Menü nach oben und den Wert für die lange Seite einstellen. Dann wieder zurück nach unten und 'Größe ändern' anklicken.


    Würde die Checkbox direkt über dem Eingabefeld 'lange Seite' stehen, so würde man mit einem Blick sofort erkennen, dass es 3 Einstellmöglichkeiten gibt - wobei die 1. die entscheidende für die korrekte Größenkorrektur ist. Dadurch wäre vermieden, dass man immer wieder in die jetzt bestehende Falle tappt.

  • Zitat von "bertram"

    Hm, da bin ich zunächst mal ratlos. Für diesen Zweck wurde in ji nie etwas programmiert. Ich selber benutze dafür die Zwischenablage und in ji "Bild > einfügen". Kann es sein, dass das Problem auf Seiten des eMail-Klient liegt? Denn mit meinem kann ich auf die geschilderte Art auch in IrfanView kein Bild einfügen und in ji ergibt sich gar keine Reaktion.


    Ich wusste doch, dass ich noch etwas vergessen hatte: Ich benutze Windows Live Mail. Bildanhänge kann ich damit nur speichern oder drucken oder (mit IrfanView) öffnen.


    Mit der von mir genannten Methode kann ich die Bilder in diverse Programme ziehen, wie IrfanView, Corel PaintShop Pro, Paint, Word, WordPad.


    Dass es nunmehr mit JI nicht mehr geht, kann nicht am eMail-Klient liegen, denn unter denselben Rahmenbedingungen laufen die Versionen bis v4.1.4.1 problemlos ( ja, ich habe sie noch alle). Wenn also nichts umprogrammiert wurde, dann müsste das wohl beim Erstellen der EXE passieren.