Re: pictures

[Magnus Bergman <magnusbe algonet se>]

On Mon, 14 Feb 2011 20:32:48 +0100
Benjamin Otte <otte gnome org> wrote:

> For now, I'm interested in high-level review of the idea. Things like
> "This whole idea is stupid because ...", "I would change the API so
> that ...", "If you did this, we could also use it for ...", "How do
> you intend to solve ..." or "I think you should not name it picture
> but ..." are what interest me.

I have some thoughts mainly related to the API for image loading
plugins.

One thing I really miss with GdkPixbuf is a way for a plugin to get
the mime type from the application. Since the application always knows
the mime type (in order to use the right plugin) should be quite
straight forward. What is the use for this then? Then writing loaders
for some obscure image formats I came across a corner case then 1:
There are several similar (but slightly different) image formats that
makes sense to put in the same plugin but 2: the image formats cannot
be distinguished by fingerprinting the first few bytes. So please
include this in the plugin API. The picture loader would also need a
way to set the mime type before loading (because sometimes the
application knows better than gio).



Then there are some other corner cases I can think of, each complete
with their own can of worms.

Some year ago there was a discussion about image formats that could
contain multiple sub-images. There was some ideas about accessing both
frames and layers with the same API. I don't remember where the
discussion ended but I think everyone agreed that GdkPixbuf API needed
replacement before the issues could be addressed. Before any decisions
are made I just want to point out that hat there can be different types
of sub-images:
1: A set of images with an undefined relationship
2: Frames of an animation
3: Layers
4: Mipmaps

There are image formats with support for more than one of these at the
same time (at least 1+2 and 2+3 that I know of).

(1): If a file just contains several images it might be enough if all
but one are simply ignored? Even thou it's supported by common image
formats (TIFF comes to mind) it's not very common practise (as far as I
know). Perhaps a concept of "pages" would be adequate (presenting the
sub-images as a list even thou they could be arranged in a tree
structure)?

(2): For case of frames I guess animations has been discussed enough
before. It has been brought up before that an animation might not be
entirely bases around the concept of consecutive frames. (Some might
have a concept of doing a certain transformation over a certain time.
Or there might be hints on how to continuously interpolate states
between the actual frames.)

(3): For layers I think it's too complex to be worth it. Keeping in
mind that a layer might be algorithmical and impossible to render on
it's own. An API to hide/show layers might not be as hard to define
thou (but I'm not saying I can think of any actual use case).

(4): There are image formats that contain actual mipmaps. But I also
like to include similar concepts under the same topic. Such as
different sizes of icons or an intelligently generated thumbnail (a
closeup on the face from a portrait image for example). In this case I
guess the most appropriate sub-image is selected based on the requested
(pixel) size. Perhaps it would be useful if a list of all "natural"
sizes could be requested?

The sub-images could also contain variants with differently sized
palettes (16 and 256 colors). Is this something to take into
consideration or do GTK (or rather cairo) consider palettes a
deprecated concept?



By the way, does Picture need to depend on GTK at all, isn't cairo and
glib enough? It would make sense with a command line program that
generates thumbnails for example. What about having:
1: A class that loads images into an abstract representation, tells
then they need redrawing and has a function for rendering to a cairo
surface.
2: A class (possibly a GTK widget) that encapsulates a cairo surface
and the abstract image, and does the rendering then needed.