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

[Kusi]

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

[Colin Guthrie-6]

Markus Leuthold wrote:
> I tried to send it to kde-imaging too, but I got rejected

Ahh well. There has been a policy change not too long ago, so perhaps
you'll need to subscribe now?

>> 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).

I really like the apple implementation if that's any help. I think it
keeps the panning AND zooming after the transition, so the photo itself
is *always* moving and zooming, even when it blends into another.

Also it has dual screen support that shows two (and sometimes four
during transitions!) images symultaniously (each display acts as a
"photo frame").

>> 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.

Cool, I thought it should be OK, but e.g. Myth somehow borked my Xgl and
now my AIGLX setup :( Hey ho I'm sure your stuff will work OK.

> 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.

I'll let you know when I get it working again (a non-beryl related Mesa
issue with my current Mandriva Cooker install!).

Cheers just now.

Also Angelo is right about slideshow maintainership. Once you finish of
putting the features of slideshow into your plugin we can maybe
deprecate slideshow completely for the next release.

If you are quick with a semi stable version of your plugin, it could
even make it into 0.1.3 release. WDYT Angelo? I wouldn't want to delay
0.1.3 but perhaps a totally new plugin can sneak in without as much
testing? It could just be called a "preview release" of the plugin and
as such come with no warrenty? Or is that just bad PR?

Col.

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