Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

On Wed, 2008-09-10 at 01:27 +0200, David Faure wrote:

I think instead of org.freedesktop.thumbnailer you want a pluggable
org.freedesktop.imageresizer namespace.

Thumbnailing is not generic resizing of images (without even storing
it), if you just resize an image and don't store it .. it's called
resizing. period.

If you indeed set up that specification and if you make a desktop
neutral prototype and it indeed becomes part of freedesktop, I'd be
happy to let this org.freedesktop.thumbnailer.Generic use the
specialized resizers in org.freedesktop.imageresizer instead of its own
specialized thumbnailers in org.freedesktop.thumbnailer implementing
org.freedesktop.thumbnailer.Thumbnailer.

Which is an architecture that I could agree with:

The org.freedesktop.thumbnailer.Generic getting a SHM from the elected
specialized resizer, and then the thumbnailer storing the resized pixbuf
as specified by the thumbnail-spec, and signaling the `Ready` signal.

Regretfully I didn't start with an existing org.freedesktop.imageresizer
being available. 

Before this kind of architecture can be done, somebody would first have
to specify (and agree on the need for a) namespace for resizing images
over DBus. Maybe you?

My POV is that current freedesktop's DBus APIs don't go that far yet,
perhaps with the exception of richer frameworks like Telepathy, and
although the idea fits my view of taking over the world, I fear this
wont happen in time. Maybe in a few years we will have this, indeed.

Therefore .. let's call that architecture:

org.freedesktop.thumbnailer 2.0 depends on
org.freedesktop.imageresizer 1.0

But if nobody is hungry for specifying a o.f.imageresizer, let's stay
with our both feet on the ground and start modest with just a namespace
like o.f.thumbnailer.


> Service or library doesn't matter, what matters is to need only one implementation
> of the data-to-image code for each type of data. If I write an EXR thumbnailer, which
> has all the code for reading a big EXR image and generating a pixmap out of it at
> any size, why shouldn't I be able to use that code even when generating larger previews?
> 
> Your suggested algorithm below...
> 
> > if (size < 256)
> >   use thumbnail service
> >     on service's callback
> >       use rescaling code on thumbnail
> > else
> >   use rescaling code on original
> 
> ... assumes that we can just get the "original" as an image. But isn't that the whole point
> of the service we're talking about, to have the implementation for original-to-image?
> So the "else" branch also needs that service.
> 
> Otherwise we could be talking about a simple service that loads/stores small PNGs into the
> on-disk thumbnail cache, but then I don't see the point in mimetype-specific plugins for it.
> If such plugins exist, then they should also be useable for generating larger previews,
> otherwise that code is just going to be duplicated, which is never a good idea.
> 
> > Just to flood the DBus system with pixbuf data?
> 
> We use SHM where available in KDE, to solve the issue of the amount of data
> being transmitted over the wire.
> 
> > The point of the service *is* to manage the cache as defined by the
> > thumbnail-spec, indeed.
> 
> That would be fine, but I don't think this is what you started specifying, since
> it also manages data-to-image conversion plugins on top of it, but limiting
> those to the thumbnail spec.
> 
> > This DBus specification *is* about remotely managing the thumbnail-spec.
> > If that specification ain't useful for your purposes, I guess this DBus
> > specification ain't going to be useful either, indeed.
> 
> I think you misunderstand me slightly. The thumbnail-spec is fine as far as 
> I'm concerned; but it's "just" about caching, nothing else.
> 
> I'm just saying that on-disk caching
> (as covered by the thumbnail-spec) isn't the only thing one should be considering
> when talking about writing code that can convert anything to images.
> 
> OK after a bit more reading I now realize that "large" is 256x256 in the thumbnail spec
> and that's exactly what konqueror & dolphin use for the big preview in the tooltip, 
> so "larger previews" isn't such a convincing use case (at least for those apps),
> let me talk about another one: generating a preview for a temporary file, 
> i.e. disabling caching because we know the file is going to be thrown
> away, so there's no point in storing the resulting thumbnail on disk.
> 
> 
> What I'm trying to say with all this is: in KDE we have the following design:
> *  PreviewJob (available in the KIO library) handles the thumbnail spec, and when it
> doesn't find something in the cache, it requests a thumbnail of a specific size.
> * That request goes to kio_thumbnail, which itself has mimetype-specific plugins
> for converting anything to images. [kio_thumbnail has support for drawing a frame 
> around the preview, and support for blending the mimetype icon over the 
> generated preview, at the plugin's request].
> 
> PreviewJob has API for letting the application decide whether the resulting thumbnail
> should be saved for later use or not. It also supports skipping files that are too big
> (based on a user-configurable value). There is full control over what happens, because
> all the logic is in the higher level, while the low level is a stupid file-to-image converter
> [with parameters including max width and height]. 
> 
> It seems to me that your suggested spec is architectured the other way round:
> the low-level file-to-image service also handles the thumbnail-spec, which means
> there is no way to request a preview at a specific size, or to request a preview without
> storing the result into the on-disk cache.
> But all this seems fixable by simply adding a way to specify a size, and whether to save the resulting image.
> Just two ints and a bool after all :-)
> 
-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be