Yeah, the orientation should be set to 0 after this action is performed. I'll try to find out if it's detectable that the plugin is invoking exactly this action....

Created attachment 20893 [details]
fugly-plugin-update-orientation.patch

Try this. It is unportable, but at least works here on gcc version 3.4.6
(Gentoo Hardened 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10).

Thank you for your very fast reply!
I haven't tested your patch. Recompiling a kernel with a patch take me 30 seconds, but I'm affraid I will take hours to recompile a kde app :-D

I understand that the plugins do there work independently from the application. The right way should be the application to decect what the plugin have done, but a fix for me can be a button "resync database info for selected images".

Another tip: the md5 of the image is changed with rotation, informations like rotation can be reset after a md5 change?

Regards

Marc

> Recompiling a kernel with a patch take me 30 seconds, but I'm affraid I will take hours to recompile a kde app :-D

It takes 12 minutes on my laptop. I'd love if someone with GCC 4 (or entirely different compiler) could test that.

I was not talking about the time of the compilation, but the time of setting-up the compilation environment without disturbing my box... found some interesting documentation about that on the kphotoalbum homepage :-D

here are some infos about what I've used for compilation:
* kphotoalbum-svn-r677561
* your patch
* libkexif-0.2.3
* libkipi-0.1.4
* kipi-plugins-0.1.0-rc2
* debian lenny
* gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

thanks for the very fast response (and FIX) :-D

Regards

Reopening as it should be fixed.

seems that I forgotted to say it clearly in comment #5...
This patch worked for me!

Regards

Hi list,
this message is a result of KPhotoAlbum bugreport [1] and an ugly patch [2].

There's a KIPI plugin that, based on EXIF information, physically
rotates the JPEG image and resets the ImageOrientation EXIF field back
to "normal". As a design choice, KPhotoAlbum doesn't rely on this EXIF
field, but rotates images according to a record in its own database
(which is typically initialized with correct data when KPA sees the
image for the first time), so users can freely "rotate" their images
without any risk to their images. This rotation can be written back to
the photos by an explicit request, but this isn't done by default for
safety reasons.

When we invoke this plugin from KPA, the real image data are rotated,
but KPA's "orientation" record in its database isn't updated.
Unfortunately we can't just re-read the respective EXIF field after each
plugin invocation for obvious reasons (this would overwrite user's changes).

What I'm looking for is how to find out that the KAction that user just
invoked is "EXIF auto rotate" from the "JPEG lossless transformations"
plugin. Right now, my ugly patch abuses C++ RTTI for that, but this is
highly unportable, ugly and suboptimal. What I propose is that each
KAction from each KIPI plugin should have an unique name (in this case,
probably "JPEGLossless/rotate_exif"). That way, KPA can find out what
the invoked plugin actually did and update its database.

Alternative is to support an equivalent of name() for each KIPI plugin,
but I'm afraid that this would require a change in the plugin ABI.

Note that we can't use regular C++'s
dynamic_cast<KIPIJPEGLossLessPlugin::Plugin_JPEGLossless> because
headers for that plugin need not be available while we build the
application.

[1] https://bugs.kde.org/show_bug.cgi?id=146927
[2] https://bugs.kde.org/attachment.cgi?id=20893&action=view

Cheers,
-jkt


Created an attachment (id=21340)
OpenPGP digital signature

Angelo Naselli wrote:
>> this message is a result of KPhotoAlbum bugreport [1] and an ugly patch [2].
> Reading that report i seem to understand we're talking about kipi-plugins 
> 0.1.0 rc2, have you expierenced the problem with a later version?


Hi Angelo,
I believe that the version of KIPI plugins doesn't matter at all. I have
no idea about what version the original submitter uses, but I've
reproduced the issue with Gentoo's libkipi-0.1.4 and
kipi-plugins-0.1.0_rc1. That said, this version information isn't
relevant at all, AFAIK.

> Gilles is on holidays by now (trying to ccing him to ping him asap)


No need to rush.

> but from NEWS file i found out the following
> 006 ==> 119537 : JPEGLossLess : Exif width and height are not corrected after lossless rotation.
> http://bugs.kde.org/show_bug.cgi?id=119537
> seems to say your problem is fixed IIUC. And that should mean the bug you're
> referring to is fixed and duplicated of bug# 119537.


Unless I'm missing something important, this bugreport is totally
irrelevant. Perhaps I wasn't clear enough, but the problem is that after
 invoking that plugin, the already rotated image is rotated by KPA once
again. This won't affect any other application, problem is that KPA
fails to recognize that the plugin actually rotated the image.

> According to plugin_jpeglossless.cpp there are more than one actions
> and related action name but I'm not the jpeglossless 
> plugin guru :)


Indeed, that's why I want to identify this action and not all actions
from that plugin. Note that the unportable part of my ugly patch is the
blurb that is trying to identify the plugin, not the action.

> Sure it would, libkipi should (*will*) change in incoming kde 4, so
> any help, suggestions, patches are welcome ;)


Provide a unique name for both each plugin and each action. The
applications should be able to identify each KAction instance alone, so
perhaps its naming of "pluginName/actionName" is reasonable.


Cheers,
-jkt


Created an attachment (id=21341)
OpenPGP digital signature

SVN commit 741620 by jkt:

Added ugly and unportable patch that at least sometimes can check if the KIPI
plugin we've just invoked is "KIPIJPEGLossLessPlugin::Plugin_JPEGLossless" and
its action is "rotate_exif". If it is, we should set image orientation in our
DB to "normal". Unfortunately KIPI Plugin maintainers haven't responded to my
queries about providing saner interface.

BUG: 146927


 M  +7 -0      ChangeLog  
 M  +38 -0     MainWindow/Window.cpp  
 M  +1 -0      MainWindow/Window.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=741620