Bug 87804

I'm using 0.7 beta 1 now and while I am not able to check whether lossless operations are used by the image viewer or not, obviously the image viewer doesn't honor enabling and disabling KIPI plugins in the digikam 'Configure' dialog box. If e.g. I disable 'JPOEG Lossless Plugin' there, options for rotating and flipping are removed from digikam main window's menus and context menus, but if I open the image viewer, they are still there.

Digikam main windows use jpeglossless kipi plugin for batch image operations.
DigikamImageeditor use a specific implementation for rotation/flipping operation on the current image.

DigikamImageEditor implementation is independant of JpegLossLess kipi plugin implementation.

In all case DigikamImagEditor don't use Kipi plugins.

Gilles Caulier

I don't understand why this was marked as INVALID.  I already know they don't use the same implementation- that is the whole point of this wish.  Who wants to use a lossy jpeg implementation to rotate an image when there is an alternative that is NOT lossy?  If you don't have time or inclination to fix that yourself, it would be nice to leave it open for someone else to fix.

1/ Digikam editor opening the jpeg file via Imlib2 API.
2/ The flipping/Rotating operations on RGBA RAW data in memory.
3/ Digikam editor writting the jpeg file via Imlib2 API. The Exif informations are restored if necessary... You can use a compression factor on setup dialog especialy for JPEG file ! Use a 100 factor for don't use compression.

Gilles Caulier

If I understand you correctly, the answer lies in bug 91542

OK, but still: why not perform lossless compression if the roatation angle is a multiple of 90 degrees ? Selecting a compression factor is not a solution, because
a) usually you don't know what compression setting your image was originally saved with
and
b) even if you knew and used the same setting, if you do a 'normal' rotation and recompress to JPEG, you could still loose image quality
and
c) it is confusing - users don't know or care that digikam and the image viewer are actually separate applications and they expect that these two windows behave in a consistent way. The fact that rotating an image in one window is lossless (safe) and rotating it in another is lossy is a big inconsistency
and
d) why would anyone want to do a lossy JPEG rotation if lossless rotation algorithm is available ? If someone wants to change their quality setting, they can use 'Recompress' - and there at least thney are warned that they may be loosing quality.

Sorry for the typo: of course I mean lossless rotation, not lossless compression. Usually we use lossy compression (because we get a better compression ratio), but we want lossless rotation (meaning: during rotation no quality is lost _relative_ to the unrotated image).

recently there has been a lot of heartburn over the lossless and lossy
jpeg rotations in digiKam. see:
http://bugs.kde.org/show_bug.cgi?id=87804 for a discussion on this.

first some preface to the problem (Note: applies only to jpeg files):

* digiKam offers lossless jpeg rotation through jpeglossless plugin,
accessible from the right click menu on the thumbnails
* the imageviewer also offers rotate options, but these are not lossless
and users seem to get confused by this. how the lossless operation works
is by NOT decoding the image, but by rearranging the encoded image data
blocks. if any operation opens(decodes) the image and then saves(encodes)
it back, it can't do the lossless operation. this is exactly what the
imageviewer does. the rotate in the imageviewer works by actually rotating
the image pixels, which have been obtained by decoding the image. the
question which frequently arises is why not make only the rotate operation
lossless. this is not possible because, for eg, lets say user does this:
rotate -> resize -> gamma correction. now the lossless operation can't
work because the other two operations have to act on the image pixels.

a possible solution is to detect if user does only rotation and use the
lossless operation then. in my opinion its equally confusing as the
current setup, as user doesn't have any indication if the rotate he's
doing currently is lossless or not.

a better compromise solution would be:

* add a new menu item in the imageviewer called as "Lossless JPEG Rotate"
  in addition to the "Rotate"
* clicking on this would rotate the image according to the angle selected,
  SAVE it and reload it in the imageviewer.
* if user has done any other operations before on the image, a error
  message will popup informing user why the lossless rotate option can't
  work in that case (and also provide hints on how to deal with it)
* in case of non-jpeg files, the operation will again popup an error
  message or maybe even disable this menu option

Does this sound like a compromise everyone can live with?

renchi

Thanks for the detailed explanation!  I like your first compromise, if I have a choice.  The only time I do a rotation (and I imagine this would be the same for 99% of other users?) is because I shot the picture vertically, i.e. 90% or 270%.  I just want to save the picture in the same orientation that I shot it in.  I'm afraid my mother and father or any other inexperienced user wouldn't understand the distinction between "lossless JPEG Rotate" and "Rotate".  I doubt they even know what JPEG is.

If I could add one more thing, I think the Windows software that comes with my parents' Canon camera automatically displays the image in the orientation it was shot in.  I'm not sure what would be involved in making this work for digiKam but that would be the ideal solution, in the future.

regarding comment #10: there is already that option in digikam. look under embedded information (in settings) -> rotate image/thumbnail based on exif information

That's great, thanks!  I can't actually test this at the moment since I'm still using 0.6.2 (no ebuild for 0.7 yet) but that will pretty much satisfy my wish.

#10 When using kamera: konqueror plugin to transfer files from my Canon.
And then viewing the images in konqueror, they are correctly rotated!

But not when using digikam...
I am usin 0.7.4 (SuSE 10.0) and it has two checkboxes (translated from Swedish)
* rotate image/thumbnail according to EXIF tag
* set EXIF tag to normal after rotation

I think they should be (dropdown)
* display image/thumbnail rotation according to EXIF tag [default, will match
  konquerors thumbnails]
* ignore rotation information in EXIF tag
* rotate image to normal permanently [resets tag]

Why?
Do not modify the files unless asked for!

Note: easiest way to rotate an image lossless is to modify the EXIF tag only!
my guess is that that is what jpeglossless does but I am not sure...

>my guess is that that is what jpeglossless does but I am not sure... 
No it doesn't
There are some explanations in this report which tolds you, why this report is invalid.