[Digikam-devel] new KIPI plugin (image viewer)

[Markus Leuthold]

> Markus Leuthold wrote:
> > While digikam is a great program for managing your photo library, it
> > doesn't exactly fit my need for presenting images in fullscreen-mode. My
> > plugin, downloadable here (http://titlis.org/kipi_imageviewer.tar.gz),
> > does:
>
> You should also post this in the kde-imaging mailing list (the home of
> Kipi Plugins). I've cross posted your mail there but due to my inability
> to think straight I sent the mail without adding this preamble and
> forgot to CC the original (this) list.... I'm an idiot... ;)

I tried to send it to kde-imaging too, but I got rejected

>
>
> Excellent - look forward to trying it!
>
> > The plugin does not yet
> > - respect image rotations in the EXIF header
> > - slideshow
> > - icons, dialogs, etc...
> >
> > I'll fix those issues soon. I'm aware of the fact that as soon as the
> > slideshow is implemented, it's quite a code duplication of the existing
> > slideshow KIPI code. I tried to reuse this code, but I finally changed
> > the datastructure which fits my needs better. But I'll reuse the
> > transition effects of the slideshow plugin.
>
> If you do and you have time, could you take a look at:
> http://bugs.kde.org/show_bug.cgi?id=102021
>
> I've been wanting that for ages :)
>
really nice, I like that wish with the dualscreen setup. Shouldn't be too 
difficult to implement. And yes, you're right, transitions must blend on 
moving images, I agree. I didn't make up my mind yet on the Ken Burns effect, 
which also keep on panning or zooming AFTER the transition is finished
(http://en.wikipedia.org/wiki/Ken_Burns_Effect). 

> > since I load the raw image into texture ram, you need quite alot of video
> > mem. E.g a 5mp image takes 20mb in the texture ram. So don't try to run
> > this plugin with less than 32mb video ram.
>
> Is this going to conflict in anyway with Compiz/Beryl or similar?
as far as I understand, there are still issues with OpenGL apps on next-gen 
window managers as Beryl. As long as the OpenGL command are not directly 
passed to the driver, it will result in a (probably small) performace drop. 
But they're working on it... I didn't get Beryl running yet due to only 
having 32mb video mem.

I didn't figure out yet what the best strategy is for displaying images: I can 
either download the entire 20MB raw data (for a 5mp jpg) to the texture ram 
and let the GPU downsample the image or I can downsample the image with 
QImage::scale() to screen resolution and then only download about 6MB to tex 
mem. Since I have a very slow AGP setup, the latter is faster on my system. I 
only load the entire 20MB to texture ram as soon as I perform zoom 
operations. Therefore, if you don't zoom you shouldn't run out of memory with 
Beryl. But I'd be interested how it acts under Beryl.

Kusi