jpg-Illuminator: Bugs und Verbesserungs-Vorschläge

    Bei ungekoppeltem Kopierstempel mittels Gummiband treten beim senkrechten Ziehen von oben nach unten folgende Fehler auf:


    meistens "Zugriffsverletzung bei..."
    oder "Ungültige Gleitkommaoperation."


    Das Gleiche passiert auch, wenn das Gummiband von links nach rechts bzw. umgekehrt gezogen wird, sofern der Endpunkt mehr als ca. 3°unterhalb des Anfangspunktes liegt.

    Ich hatte letzt die gleiche Fehlermeldung, kann es aber nicht reproduzieren. Auf jeden Fall hatte ich auch die Kopierquelle mittels Shift- und Strg-Taste festgestellt (ist ja leider die einzige Möglichkeit auch wenn kein Haken bei "Koppeln" etwas anderes suggeriert).

    Gruß softride
    Lumix GM1, GX7, GX80, GX9, G9, P 7-14, P 8, PL 1,7/15, P 12-32, O 1,8/45, O 2,8/60, O 1,8/75, P 14-140 II, PL 50-200 + TC14, PL 100-400

    Der Fehler ist vom Winkel zur Horizontalen abhängig. Es gibt 3 Bereiche:


    Kleine Winkel: keine Probleme
    Mittlere Winkel: es wird nichts kopiert
    Größere Winkel: Fehlermeldung


    Winkelangaben kann ich keine machen, denn sie schwanken. Die Reihenfolge der Ereignisse bleibt jedoch mindestens bis zum Setzen eines neuen Quellpunktes gleich. Dieses führt natürlich zu Problemen der Reproduzierbarkeit. Auch scheint die Länge des Gummibandes einen Einfluss auf die Fehlermeldung zu haben.


    Die Strg-Taste hat auch ohne die Gummiband-Funktion die Aufgabe, nur den Bereich des gesetzten Quellpunktes zu kopieren. Auch hier spielt es keine Rolle, ob "Koppeln" mit oder ohne Haken. Da ist es folgerichtig, dass die Arbeitsweise beim Gummiband gleich ist.

    Oh, ich bin noch bei 4.7.5.9 :oops:


    Ich kann es aber sowieso nicht mehr reproduzieren und es trat nur einmal auf.

    Gruß softride
    Lumix GM1, GX7, GX80, GX9, G9, P 7-14, P 8, PL 1,7/15, P 12-32, O 1,8/45, O 2,8/60, O 1,8/75, P 14-140 II, PL 50-200 + TC14, PL 100-400

    Jawohl, Version 4.7.6.0!


    Der Fehler tritt aber auch bei Versionen bis herab zu 4.7.3.0 auf, jedoch nicht bei 4.7.2.8 oder 4.7.2.3.


    Kann die Grafikauflösung oder der Grafiktreiber eine Rolle spielen? Ich arbeite an einem UHD-Monitor mit Intel HD Graphics 4600.

    Wenn man Scans mittels eines auf den Scanner abgestimmten Scan-Programmes (z.B. Canon Navigator EX) herstellt, werden EXIF-Daten erzeugt, die Ji leider komplett ignoriert. Vielleicht lassen sich einige Inhalte beim Anzeigen der Bilder sichtbar machen.



    Benutz man beim Ausrichten die Funktion "automatisch beschneiden", so erfolgt dieses im Seitenverhältnis des aktuellen Bildes. Scans sind meistens nicht genau in den üblichen Seitenverhältnissen erstellt. Daher wäre eine zweite Möglichkeit wünschenswert, um das Bild mit dem im Dialog "Bild beschneiden" eingestellten Seitenverhältnis zu beschneiden. Ganz toll wäre es, wenn JI erkennen würde, ob es sich um ein Bild im Hoch- oder Querformat handelt und das Seitenverhältnis entsprechend umstellen würde, z.B. satt 3:2 also 2:3, so wie es bereits im Dialog "Druck-Vorschau" praktiziert wird.

    • Offizieller Beitrag

    Danke für deine Anregungen!
    Über das Seitenverhältnis beim "automatisch beschneiden" werden wir nachdenken.
    Der Wunsch nach diversen EXIF-Daten beim Scan wird wohl leider ein Wunsch bleiben. Uns fehlt jeglicher Ansatzpunkt, vom Scanner EXIFs zu ermitteln. Und wir haben auch nicht vor, in diesen Sachverhalt viel Zeit zu investieren. Unsere jetzige Methode überträgt das Bild vom Twain-Modul über die Zwischenablage, wobei zwar eine dpi-Zahl im Header übertragen werden kann aber nicht EXIF-Daten. Und bereits die dpi-Zahl bereitet uns Probleme ...


    Übrigens: Das von dir entdeckte Zugriffsproblem beim Gummibandstempel wird demnächst behoben sein.

    Zu den EXIF-Daten bei Scans muss ich noch etwas ergänzen: Ich meinte nicht ein über JI erzeugtes Scan-Bild, sondern wie an dem hochgeladen Bild erkennbar, ein mittels der Software "MP Navigator EX 5.0" auf dem Drucker "Canon MG8200 series" erstelltes Bild. Dieses Verfahren hat den Vorteil, dass mit einem einzigen Befehl 6 Bilder nacheinander gescannt werden und man sich dadurch bis zum weiteren Scanbefehl 13 Minuten lang anderen Aufgaben widmen kann. Bei anderen Scannern wird das ähnlich sein. Speichert man solch ein Bild mit Ji, so wird in den EXIF-Daten der Eintrag für die Software durch Jpg-Illuminator ersetzt.


    Wird ein über JI ein Bild gescannt, so ist in der gespeicherten Datei ...ji.jpg u.a. bei DateTime und DateTimeOriginal ein Datum eingetragen. Bei Aufruf eines solchen Bildes wird in der Info-Zeile ein Datum angezeigt, offensichtlich das der Zeile DateTimeOriginal. Da bei den fremd-gescannten Bildern das Datum statt bei DateTimeOriginal bei DateTimeDigitized eingetragen ist, wird deshalb wohl in der Info-Zeile von JI kein Datum angezeigt. Vielleicht kann aber DateTime zur Anzeige herhalten und dann sicher auch der Eintrag in der Zeile Model.


    Zum JI-Scan: Lässt sich in den EXIF-Daten des gespeicherten JI-Original-Scans nicht bereits Datum und Auflösung eintragen?



    Bilderpaare: links fremdgescanntes Bild, rechts über JI gescannt

    Schaut euch das doch mal an, vielleicht könnt ihr damit die Ausgabequalität noch weiter erhöhen, schön wäre es wenn man zwischen den beiden Methoden wählen könnte.


    Google reduces JPEG file size by 35% | Ars Technica UK


    Grüße

    • Offizieller Beitrag

    So wie ich es verstehe, geht's dabei in erster Linie um das Einsparen von Speicher bzw. Bandbreite:

    Zitat von guetzli

    Guetzli is a JPEG encoder that aims for excellent compression density at high visual quality. Guetzli-generated images are typically 20-30% smaller than images of equivalent quality generated by libjpeg. Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer.

    Bei offenbar exorbitantem Speicherbedarf:

    Zitat von guetzli

    Guetzli uses a large amount of memory. You should provide 300MB of memory per 1MPix of the input Image.

    Im Heise-Forum hat außerdem jemand geschrieben, dass der Encoder extrem lange rechnet.


    Mir scheint, der Aufwand zur Integration (der wäre erheblich wegen der EXIF-Daten) steht in keinem Verhältnis zum Nutzen für den ji-Anwender.


    Wer möchte, kann mit dem jpg-Illuminator aber PNGs speichern (das ist verlustfrei) und diese dann mit guetzli umwandeln.

    • Offizieller Beitrag

    Dazu haben wir uns viele Gedanken gemacht und eine neue Funktion "Farbangleichung" entwickelt. Bei deinem Problem liegt ja in der Regel weder ein linearer noch ein radialer Farb-/Helligkeitsverlauf vor. Wir haben die Interpolation mit einer distanzbasierten Berechnung umgesetzt.

    Danke, das ist Mega-Genial!
    Ich habe jedoch den Eindruck, daß der Kontrast darunter leidet (zumindest bei der Methode "hellster Punkt"). Kann es sein, daß ihr "einfach" abhängig von der Entfernung alle Werte um die Differenz (ich nenne es lokal den [Aktueller Korrekturwert]) abzieht? Eine entsprechende "Spreizung" des Restes wäre da vielleicht zielführender, so nach der Art [Neuer Wert] = ( [Alter Wert] - [Aktueller Korrekturwert] ) * 256 / (256 - [Aktueller Korrekturwert])


    Ach, und noch: rechte Maustaste: Punkt wieder löschen.


    Und wo ich schon dabei bin:
    "grüner Button": "gedrückt halten: Farbanpassung aus"
    "blauer Button": "gedrückt halten: Farbanpassung als Maske anzeigen" (so als Graustufen-Maskenbild)

    • Offizieller Beitrag
    Zitat von wilsberg

    Eine entsprechende "Spreizung" des Restes wäre da vielleicht zielführender, so nach der Art [Neuer Wert] = ( [Alter Wert] - [Aktueller Korrekturwert] ) * 256 / (256 - [Aktueller Korrekturwert])

    Verstehst du unter Rest die Pixel, die nicht einer der Referenzpunkte sind? Mir ist nicht klar, wie wir mit dieser "Spreizung" eine Farbangleichung bekommen. Beispiel: der hellste Referenzpunkt (A) hat einen Wert von 200. Ein weiterer Referenzpunkt (B) hat einen Wert von 180. An der Stelle B ist nach der Methode "hellster Punkt" der Korrekturwert +20, irgendwo in der Nähe von B (Punkt C) ergibt die Interpolation den Korrekturwert +18.
    Wenn Punkt C so hell ist wie B, ergibt diese Formel 185 als neuen Wert.
    Wenn Punkt C dunkel ist (Wert 50), ergibt diese Formel 64 als neuen Wert.
    Wenn Punkt C schwarz ist (Wert 0), ergibt diese Formel 17 als neuen Wert.
    Ergebnis: Wenn C dunkel ist, unterscheidet sich diese Spreizung kaum vom bisherigen Verfahren, wenn C ähnlich hell ist wie B, ist die Korrektur viel zu gering. Wir erhalten damit keine Farbangleichung.
    Kann aber auch sein, dass ich dich falsch verstanden habe. (?)


    Nachtrag:
    Bestimmt ist es aber sinnvoll, gegen den Kontrastverlust noch was zu unternehmen.