JPEG lossless crop

[Sebastian Roeder]

First a happy new year to the digikam team - may it not be totaly overworked
in 2006 by the ambitious digikam project.

During christmas holidays I prepared some digikam photos for print. That means
I used the crop w/ ascect ratio to transform them from 4:3 to 3:2 ascpect
ratio. Sadly this transformation is not lossless in digikam. That's bad cause
the photo quality is important in this case (print) and no other effects were
used. So if one could do the crop lossless  the image quality would not
descrease.

Using another file format is not an option here cause the print houses expect
jpeg and I don't want it to be to complicated (have to explain it to my
parents who are not that familar with computers).

I googled a bit and found out that a lossless crop function was implemented in
jpegtran (on Gentoo part of the "jpeg" package). Now my question is whether
there is a chance to implement this in digikam/image plugins/kipi-plugins
whatever (sorry but I do not have an overview about the digikam packages
anymore).

This is just an idea for discussion and in no way a "I want this and I want it
now" request. I know that you all have a lot of work with the 0.9.x digikam.
If the discussion shows positive feedback I will add a feature request.

In the meantime it would be nice if somebody could tell me an alternative GUI
for Linux that uses the lossless crop function from jgegtran.

Thanks in advance,
Sebastian
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

Le Mardi 3 Janvier 2006 18:56, Sebastian Röder a écrit :
> First a happy new year to the digikam team - may it not be totaly
> overworked in 2006 by the ambitious digikam project.

Thanks.

>
> During christmas holidays I prepared some digikam photos for print. That
> means I used the crop w/ ascect ratio to transform them from 4:3 to 3:2
> ascpect ratio. Sadly this transformation is not lossless in digikam.

No. Image editor work only on decode image data in RAW format, not directly
with JPEG file (in your case).

Crop tool working with RAW data (decode by jpeg loader). the image alterations
result of jpeg re-encoding when file is saved because... JPEG file format is
_NOT_ a loss less file format !!! If you want more inforamtions about how to
manage _properly_ your images, take a look in digikam handbook :

http://docs.kde.org/development/en/extragear-graphics/digikam/index.html

To reduce JPEG alteration, use an adapted compression level  in settings
dialog... but this way isn't the ultimate solution : you need to use a loss
less file format like PNG or TIFF to manipulate/transform your images. JPEG
file format is dedicaced to web image publishing, not image
transformations !!!

> That's
> bad cause the photo quality is important in this case (print) and no other
> effects were used. So if one could do the crop lossless  the image quality
> would not descrease.
>
> Using another file format is not an option here cause the print houses
> expect jpeg and I don't want it to be to complicated (have to explain it to
> my parents who are not that familar with computers).

no and no. This task will not be complicated when on the fly image files
conversion will be implemented in camera interface (typically to convert JPEG
to PNG of TIFF) without lost all meta-data, ICC profiles, embedded thumbs,
etc. It's planed to digiKam 0.9.x series...

>
> I googled a bit and found out that a lossless crop function was implemented
> in jpegtran (on Gentoo part of the "jpeg" package). Now my question is
> whether there is a chance to implement this in digikam/image
> plugins/kipi-plugins whatever (sorry but I do not have an overview about
> the digikam packages anymore).

Only batch rotation operations from main interface (using a kipi plugin) are
loss less with JPEG. This is have no sence to create a crop image tool in
kipi without to have an interaction with user like in image editor...

regards

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia wtorek, 3 stycznia 2006 20:35, Gilles Caulier napisał:
> > Using another file format is not an option here cause the print houses
> > expect jpeg and I don't want it to be to complicated (have to explain
> > it to my parents who are not that familar with computers).
>
> no and no. This task will not be complicated when on the fly image files
> conversion will be implemented in camera interface (typically to convert
> JPEG to PNG of TIFF) without lost all meta-data, ICC profiles, embedded
> thumbs, etc. It's planed to digiKam 0.9.x series...

But will be on-the-fly conversion implemented for export?

Still there is no good way to export images just to folder external to
digiKam collection.

m.
--
I am social scientist - I don't know the difference between good and
bad, only the difference between difference.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

Le Mercredi 4 Janvier 2006 14:28, Mikolaj Machowski a écrit :

> Dnia wtorek, 3 stycznia 2006 20:35, Gilles Caulier napisał:
> > > Using another file format is not an option here cause the print houses
> > > expect jpeg and I don't want it to be to complicated (have to explain
> > > it to my parents who are not that familar with computers).
> >
> > no and no. This task will not be complicated when on the fly image files
> > conversion will be implemented in camera interface (typically to convert
> > JPEG to PNG of TIFF) without lost all meta-data, ICC profiles, embedded
> > thumbs, etc. It's planed to digiKam 0.9.x series...
>
> But will be on-the-fly conversion implemented for export?
>
> Still there is no good way to export images just to folder external to
> digiKam collection.

No. The files will be converted on the target album selected for download.

regards
--
Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Sebastian Roeder]

> Le Mercredi 4 Janvier 2006 14:28, Mikolaj Machowski a ?crit?:
> > Dnia wtorek, 3 stycznia 2006 20:35, Gilles Caulier napisa?:
> > > > Using another file format is not an option here cause the print
> > > > houses expect jpeg and I don't want it to be to complicated (have to
> > > > explain it to my parents who are not that familar with computers).
> > >
> > > no and no. This task will not be complicated when on the fly image
> > > files conversion will be implemented in camera interface (typically to
> > > convert JPEG to PNG of TIFF) without lost all meta-data, ICC profiles,
> > > embedded thumbs, etc. It's planed to digiKam 0.9.x series...
> >
> > But will be on-the-fly conversion implemented for export?
> >
> > Still there is no good way to export images just to folder external to
> > digiKam collection.
>
> No. The files will be converted on the target album selected for download.

This does not solve my problem cause most online photo services want jpg. I
would have to convert from tiff/png > jpg at the end of the process, no
matter how easy it is to convert from jpg > png/tiff on download. And here
again the whole jpg > png > jpg thing becomes losy.

The idea of automatic conversion on download is great for most image
manipulation tasks (I'm looking forward to have this feature - honesly I
didn't know that png is lossless) but not for the one and very common task to
recieve (jpg) photos from a standard digikam (that means no RAW available)
crop it to the right ascpect ratio for printing (that is 2:3 aspect ratio)
and send the jpgs to an online printing service without a quality loss.

The ratio crop in digikam does just that (and does it great) but it is lossy.
Now I would say OK I have to live with that and it is a jpg limitation but IT
IS NOT! JPEGTRAN CAN DO THIS JOB LOSSLESS (that means without recoding)!

See this link for details: http://sylvana.net/jpegcrop/

I don't know the internals of the existing ratio crop tool in digikam but my
question is whether one could a) use jpegtran as "backend" to do the job
lossless (downside: another dependency - but jpeg tools should be installed
on every linux distro) or b) adopt some code of the jpegtran lossless crop
functionality into digikam.

I hope I made things a little more clear now - it's always hard to explain
such complicated things in a foreign language without beeing misunderstood.  
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Am Mittwoch 04 Januar 2006 23:13 schrieb Sebastian Röder:
> Re: [Digikam-devel] JPEG lossless crop

you have a private mail in German to clarify these things :-)

Bye

  Thorsten

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Sebastian Roeder]

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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel