[KimDaBa] New snapshot: "Patch" for thumbnails and questions/ideas about plugins
Reimar Imhof
Reimar.Imhof at netCologne.de
Sun Jul 25 20:47:21 BST 2004
Am Sonntag, 18. Juli 2004 17:23 schrieb Jesper K. Pedersen:
> After 3 month, a new snapshot is now available from:
> http://ktown.kde.org/kimdaba/snapshots/
>
> WARNING: We are still working on what images are effected by a plugin,
> which means that currently all images in scope (which might mean your whole
> database) are effected if nothing is selected.
> So before you start playing with unknown plugins, please try with a demo
> database first (run kimdaba -demo)
>
> Cheers
> Jesper.
Hello Jesper,
with the new snapshot I got a problem about thumbnails created for the
Ctrl-T-thing:
These 256x256-thumbnails are build with a terrible quality.
I had a look at imageloader.cpp.
Here I found your hack (line 89 - 93).
I disabled the hack (removed those lines) and everything is fine.
The problem was this: A 64x64-thumbnail was created. This one was set to the
variable img in line 75.
Then, within the hack, that image was scaled to 256x256.
To compare I had a look at the last snapshot (2004-04-18).
That one didn't have that problem because the original image was scaled to
256x256.
On the other hand: The hack did work only if you had the standard size for
that Ctrl-T-images (256X256). If you choose an other size (for example
512x512) the 256-thumbnails were created for nothing...
(I do not apply a patch file with this mail because my change is so terrible
simple!)
Two things about the plugin interface:
Selection:
I'd like a pseudo album with the images actually selected (via search
functionality) within kimdaba. And I could also think of a second pseudo
album with those images actually selected by mouse. So I could search for
some pictures within kimdaba (get perhaps 10 images), then select 3 of them
by mouse and tell the plugin just to take that second pseudo album to get the
manually selected images. If I take the first pseudo album I get the Images
actually found by the kimdaba search.
Rotation:
Kimdaba by default does not rotate images but stores an rotation angle in its
index.xml file.
When I put rotated images to an kipi plugin the plugin does not care about the
rotation. Just a little sad :-(.
Could kimdaba create temporary rotated files and put these rotated images to a
plugin? This thing should be configured in the kimdaba options dialog (plugin
section). There we could have a second check box ("use temporary rotated
images").
In case a plugin changed a temporary image kimdaba could update the original
file form the temporary one (using a second rotation, the other way round of
course!).
Different approach: Kimdaba could have a new menu entry for rotating an image
(some images) via lossless jpeg rotation according to the index.xml rotation
angle (and then set that angle to 0)? This could also be helpfull without
thinking about plugins.
And what about configure the rotation behavior in a general way: Kimdaba could
have two radio buttons in it's configure dialog. One says "store rotation
angle in index.xml file" (that's what is done today), the other on says
"rotate image via lossless jpeg rotation".
If you turn on the second radio button, every rotate within the image
properties dialog would use jpeg rotation and keep the rotation angle within
the index.xml file as 0.
I hope these remarks could help you.
Bye
Reimar
More information about the Kphotoalbum
mailing list