[Digikam-devel] JPEG lossless crop

[Sebastian Röder]

Hallo Thorsten,

vielen Dank erstmal allgemein für deine ausführliche Antwort. Mir ist erst 
spät aufgefallen, dass ich an die digikam-devel und nicht an die *-user Liste 
geschrieben habe. Hier sind wohl einige technische Kenntnisse über digkam and 
friends Voraussetzung, die mir aber fehlten.

> ich machs mal auf Deutsch, das ist einfacher. digiKams Ratio-Crop-Tool
> arbeitet prinzipbedingt natürlich verlustfrei, wie alle Operationen im
> Imageeditor (IE). 
Danke, nützliche Info. Es wäre aber sicherlich mal eine interessante Idee zu 
erfgragen, wieviel die Nutzer von digikam über das Konzept der 
unterschiedlichen Programmteile wissen (also IE, showphoto, kipi, ...). Ich 
find das erst mal ziemlich verwirrend.

> Zusammengefasst ist dein Wunsch, eine Funktion von duzenden für nur ein
> bestimmtes Dateiformat bei gleichsam identischen Dateispeicherformat zu
> optimieren nicht realistisch, genauso wirst du diese Optimierung bei keinen
> anderen Bildeditor wie z.B. Gimp oder Cinepaint finden.
OK, sehe ich ein. Aber ich hab ja gar nicht danach gefragt es in den IE zu 
implementieren, sondern allgemein in digikam (wo bleibt doch den Entwicklern 
zu entscheiden). Allerdings wäre es doch merkwürdig, wenn es zusätzlich zum 
ratio crop im IE noch an einer anderen Stelle diese Funktion gäbe - auch wenn 
dann kipi und nicht image-plugins verantwortlich ist. Das sollte schleißlich 
transparent für den user sein.

> Der Ansatz JPEG als Bildbearbeitungsformat zu gebauchen ist denkbar
> unglücklich und hier solltest du deinen Workflow anpassen: Wenn deine
> Kamera nur JPEG-Bilder liefert, ist dieses Bildmaterial dein digitales
> Negativ und das sollte auch so gesichert werden. Sobald du dein Bild
> bearbeitest, wird generell nur PNG als lossless-Format verwendet. Für den
> Export in ein Zielbildformat hast du dann nur einmaligen Verlust, der aber
> bei einer hohen Qualitätseinstellung praktisch unsichtbar ist. Bei JPEG ist
> realistisch nur das wiederholte Speichern kritisch, die einmalige
> Neutranscodierung ist aber absolut unkritisch.
Auch hier hab ich ja zugestimmt und auf die besondere Stellung der Aufgabe 
"Seitenverhältnis anpassen für den Druck" hingewiesen. Ich hab testweise eine 
jpg Datei minimal beschnitten und trotzdem ist sie auf 30% der ursprünglichen 
Dateigröße geschrumpft (bei 85% jpg Qualität - mehr ist nicht sinnvoll). Wenn 
das verlustfrei möglich wäre, dann könnte man das Ergebnis nach dem 
Beschneiden als neues Negativ benutzen (d.h. in original-Qualität aber nur 
der Ausschnitt, der interessiert). Für weitere Bearbeitung treffen dann 
wieder deine Anmerkungen zu png zu.

> Nun wird dich das sicher nicht wirklich zufrieden stellen, deswegen will
> ich deinen Wunsch in andere Bahnen lenken. Was du willst, ist keine
> Bearbeitung im IE sondern du willst eigentlich ein Kipi-Plugin. Ein solches
> (digiKam übergreifend funktionierendes)  Bildbearbeitungsmodul darf die von
> mir oben erwähnten Einschränkungen besitzen. So arbeiten einige Module wie
> das Drehen eines Jpeg-Bildes in der Albumansicht schon jetzt mit jpegtrans
> verlustlos.
Frage: wenn ich im IE ein Bild drehe, ist das dann NICHT verlustlos, d.h. wird 
dann ein IE-plugin statt des kipi-plugins verwendet? Wenn ja, warum? Kann man 
nicht digikam je nach Datei-Typ wählen lassen, ob es kipi-plugin (mit 
jpegtran) oder IE-plugin benutzt? Wieder meine Bitte: macht das transparent 
für den User - was "under the hood" passiert ist doch schnurz. Aber es kann 
nicht sein, dass in digikam an einer Stelle eine Operation verlustfrei ist 
und an der anderen verlustbehaftet ...
 
> Hier könnte man sich speziell für JPEG-Bilder ein Modul vorstellen, das
> ähnlich wie der RAW-Konverter für Einzelbilder ein separates Fenster
> öffnet, wo man Ränder aufziehen kann und Seitenverhältnisse beachtet.
> Dabei kann sicherlich einiges an Code aus Gilles IE-Ratio-Crop-Plugin
> kopiert werden. Der Unterschied zum IE ist natürlich offensichtlich: Ein
> solches Kipi-Modul besäße keinen Speichern-Dialog - die Bearbeitung findet
> auf eine bestimmte Datei statt. In ähnlicher Weise wäre z.B. auch ein
> Kipi-Modul zur "verlustlosen" Entfernung von Hotpixeln aus Jpeg-Dateien
> möglich.
Wie ich schon weiter oben schrieb, wäre das zwar für mich eine gangbare Lösung 
in dem Sinne, da ich (weil ich es jetzt weiß) diese Funktion nutzen könnte. 
Allerdings ist das meines Erachtens aus Usability-Sicht ein Grauen, weil der 
User intuitiv den IE für diese Zwecke nutzen wird (und da ja die gleiche 
Funktionalität auch vorhanden ist als verlustbehaftet). Außerdem werden die 
Menüs immer unübersichtlicher, wenn man Funktionen derart "dupliziert". 
Vielleicht sollte man mal mit den Leuten von Open-Usabilty.org 
zusammenarbeiten in diesen Fragen?

RAW-Formate haben da vielleicht einen etwas anderen Stellenwert, weil sie nur 
von erfahreneren Leuten eingesetzt werden und immer schon spezielle Software 
benötigte. Aber wie bitte soll man rechtfertigen, dass man jpgs NICHT im 
Image-Editor bearbeiten sollte, sondern an anderer Stelle? Jpegs sind doch 
ein Synonym für Digitalphotos wie mp3s für digitale Musik ... 

> Ich hoffe, ich konnte dir klar machen, das der IE kein JPEG-Editor ist und
> hier nach dem Laden des Bildes das Urformat des Bildes nicht mehr bekannt
> ist. Alle Funktionen des IE finden in einem formatlosen Datenspeicher statt
> - ohne Ausnahme.
Ja, diesen Ansatz habe ich jetzt verstanden, aber ich habe das Gefühl, dass er 
zu sehr aus der Developer-Perspektive gedacht ist. Welches "backend" eine von 
mir gewählte Aufgabe am besten erledigt, dass sollte doch bitte die Software 
entscheiden. Gerade mit der Linux-Philosophie "für jede Aufgabe ein kleines 
Tool" ist es schier unmöglich, bei jeder GUI zu schauen, welches Programm im 
Hintergrund werkelt. Dann kann ich ja auf die GUI verzichten und alles in der 
Shell machen. Das wir uns nicht falsch verstehen: ich sage NICHT, dass der 
User nicht in der Pflicht steht sich über die Grundzüge des digital imaging 
zu informieren. Ich war Chefredakteur/Layouter einer Schülerzeitung und hab 
immer wieder versucht, meine Redakteure dafür etwas schulen. Aber in dem 
vorliegenden Fall wäre es selbst mit diesen Kenntnissen nicht möglich das 
Problem zu lösen, weil man nicht erwartet, dass zwei gleichlautende 
GUI-Funktionen an unterschiedlichen Stellen hinter den Kulissen 
unterschiedlich arbeiten.  

So, ist leider etwas länger geworden. Ich hoffe mein eher User-Zentrierter 
Ansatz bringt auch einige neue Ideen/Ansatzpunkte für dich und freue mich auf 
weitere Diskussionen zu dem Thema. 

MfG Sebastian