An alternative to gdk-pixbuf

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Magnus Bergman-3
On Fri, 7 Sep 2018 17:28:04 +0000
Debarshi Ray <[hidden email]> wrote:

> Hey Magnus,
>
> I haven't yet worked my way through the whole thread. It's pretty
> long and will take me a while longer, but I did want to mention a
> few things before the weekend draws me away from the computer.
>
> On Wed, Sep 05, 2018 at 12:02:45AM +0200, Magnus Bergman wrote:
> > Over the years it has been discussed from time to time to replace
> > gdk-pixbuf with something else[1][2]. Something was even in the
> > making (I guess over ten years ago) but it never replaced gdk-pixbuf
> > apparently. Now I don't even remember what it was called. And
> > something else called pig was proposed more recently.  
>
> As Emmanuele mentioned, if you ignore the use-case of loading icons
> in GTK, and focus on image applications dealing with high resolution
> images, then GEGL [1] is the way to go. It's a GObject-based image
> processing framework that's used by GIMP and GNOME Photos, and is
> way more advanced than anything that we have in the GNOME platform.
>
> If you use GIMP 2.10 or practically any version of GNOME Photos, then
> all the image decoding and processing is happening with GEGL.
>
> A GeglBuffer is the equivalent of GdkPixbuf in GEGL. It can:
>
> (a) Be converted to and from a GdkPixbuf. That makes porting trivial
>     and boosts interoperability.
>
> (b) Handle massive images that are larger than the amount of physical
>     RAM available on the system. This is achieved by spliting the
>     pixels into smaller tiles that get transparently swapped out of
>     memory into a disk-backed cache when necessary.
>
>     It can be dumbed down into a GdkPixbuf-like linear sequence of
>     bytes, if need be.
>
> (c) Represent a whole horde of pixel formats, colour spaces, bit
> depths, etc. [2], which can be programmatically extended at run-time.
>
> (d) Automatically convert between pixel formats, colour spaces, bit
>     depths, etc., with accelerated fast paths.
>
> (e) Be serialized into a named file, which is interesting for passing
>     pixels across process boundaries.
>
> (f) Use mipmaps for scaling, rendering and processing the pixels.
>
> (g) Be used with OpenCL.
>
> (h) Do all that and is still fast. Try zooming in and out in GNOME
>     Photos.
>
> Not to mention a vast array of image processing operations. If it's in
> GIMP, it's in GEGL. Interesting operations are ported from elsewhere,
> and there's a constant flow of new things under development.

GEGL is certainly impressive. Especially the ability to handle images
larger than RAM, I think. I must admit that it was some years ago that
I looked at the API and concluded that it couldn't do everything I
wanted from a general purpose image loading library (for image
viewing). Back then it could only load images from disk (but I've heard
that has changed at least). And as far as I know it still only does
raster images, not vector images. It also has no support for
animations, not to mention vector animations. Or rather, it can't (or
couldn't) distinguish between the concepts of animation frames, layers,
variants (which I explained earlier), stereoscopic images and files
that simply contains multiple images with an otherwise unspecified
relation (which I call pages in lack of a better term). I don't know
about aspect ratio correction, but I don't think GEGL has it. Some of
those things might get added to GEGL. But I doubt vector animations
will ever be considered. I will, however, take a new look at GEGL and
see if it's the best solution for at least some of the problems I want
to solve.

> > One major reason to replace gdk-pixbuf has been the long term goal
> > to phase out GDK in favour of cairo.  
>
> De/encoding images and manipulating the pixels is related to rendering
> them on the screen, but aren't necessarily the same thing. It's
> important to ensure that the pixels can be efficiently drawn, but I
> wouldn't add a hard dependency on the drawing framework. For example,
> GEGL has fast paths for drawing with Cairo, but doesn't mandate it.
> It also doesn't require GTK, even though it has helper widgets for it.
>
> That's why GIMP 2.10 and GNOME Photos can use the same libgegl-0.4.so,
> even though they use different widget toolkits (GTK 2.x versus 3.x).
>
> > This is how to convert an SVG file to a PNG file.
> >
> >     cairo_surface_t *surface = abydos_load("image/svg+xml",
> >     "example.svg"); cairo_surface_write_to_png(surface,
> > "example.png"); cairo_surface_destroy(surface);
> >
> > This is how to convert the second frame of a GIF animation to PNG.
> >
> >    abydos_t *ar = abydos_create_from_file("image/gif",
> > "example.gif"); abydos_set_frame(ar, 1);
> >    cairo_surface_t *surface = abydos_get_image_surface(ar, 0);
> >    abydos_destroy(ar);
> >    cairo_surface_write_to_png(surface, "example.png");
> >    cairo_surface_destroy(surface);  
>
> I don't see any error handling. Maybe I should read the actual code.

I just intended to show the general code flow so I left out the error
handling. Both abydos_load() and abydos_create_from_file() are
convenience functions that will simply return NULL if they fail. It's
possible to separate the process into more steps for a more fine
grained error handling. The other functions, abydos_set_frame() and
abydos_get_image_surface() are guaranteed not to fail (provided there
were no prior errors). See: http://snisurset.net/code/abydos/api/

> [...]
>
> Of course, one could use the GdkPixbuf codecs for I/O and then covert
> to and from a GeglBuffer. But then you wouldn't be able to handle RAWs
> or higher bit-depth PNGs and will likely run into problems with your
> 80 megapixel images [4] - things that a good image application will
> care about. :)

I expect a general purpose image viewer to handle images of that size
too. That's even small enough to fit in RAM. (But I have tested and am
aware of the problem.) Many fields of science deal with images of multi
gigabyte sizes. Ideally any image viewer should be able to handle these
too with the right plugin (probably using GEGL in that case). But I
think the problem with large images (say 12000x12000 or so) is giving
it to the application as a pixmap. From my own tests it seams it's fine
at least as long as the images are no bigger than the screen. So if the
drawing (and implicitly also scaling) is handed over to the loading
library (which in turn might hand it over to the plugin), this problem
can be avoided. Even without the really big muscles of GEGL in most
cases. But of course there is no point in not using GEGL if I can't
manage to come up with anything faster (faster loading and fast enough
drawing that is).

> > I've been in contact with a two creators of image viewers  
>
> Which ones? Just curious. :)

Oh, man, it was quite a while ago then I think about it. My quest for a
general purpose image viewer reaches back over 20 years. And I've been
following gdk-pixbuf for over 15. The first one was some guy who, like
me, was interested in the art scene and was developing a viewer to
handle those kind of image formats. It didn't take off and I don't think
he ever made a public release. The other one was closer in time, but
then I think about it almost 10 years ago. It was an image viewer I
used a lot, but seamlessly replaced with the very similar (but better)
viewer viewnior. I'm kind of surprised myself that I don't remember the
name. I think it was something quite anonymous, GTK Picture, GImageView
or something like that. Not much of a hint, but you might be able to
guess? Time certainly flies.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Debarshi Ray-2
On Sun, Sep 09, 2018 at 02:57:30AM +0200, Magnus Bergman wrote:
> Many fields of science deal with images of multi
> gigabyte sizes. Ideally any image viewer should be able to handle these
> too with the right plugin (probably using GEGL in that case). But I
> think the problem with large images (say 12000x12000 or so) is giving
> it to the application as a pixmap. From my own tests it seams it's fine
> at least as long as the images are no bigger than the screen. So if the
> drawing (and implicitly also scaling) is handed over to the loading
> library (which in turn might hand it over to the plugin), this problem
> can be avoided.

Even if one does decode the entire full resolution image into a tiled
data structure (say, GeglBuffer), there's no need to create a Cairo
surface for the entire image at 1:1 zoom. All that's needed is a
surface to represent the visible area at the visible zoom. That's a
lot more manageable.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Gtk+ - Dev - General mailing list
On Mon, 10 Sep 2018 at 08:02, Debarshi Ray <[hidden email]> wrote:

> > too with the right plugin (probably using GEGL in that case). But I
> > think the problem with large images (say 12000x12000 or so) is giving
> > it to the application as a pixmap. From my own tests it seams it's fine
> > at least as long as the images are no bigger than the screen. So if the
> > drawing (and implicitly also scaling) is handed over to the loading
> > library (which in turn might hand it over to the plugin), this problem
> > can be avoided.
>
> Even if one does decode the entire full resolution image into a tiled
> data structure (say, GeglBuffer), there's no need to create a Cairo
> surface for the entire image at 1:1 zoom. All that's needed is a
> surface to represent the visible area at the visible zoom. That's a
> lot more manageable.

I make a gtk viewer that can display large images efficiently (over
100,000 x 100,000), linked above. I hit a few other issues:

1. You can't use a large ScrolledWindow and only paint the visible
area, since you can easily go over the 64k pixel limit on viewports.
You have to handle all the scrolling yourself.
2. You need to keep all image processing in a set of background
threads and update the display asynchronously, perhaps this is
obvious.
3. You have to do the double-buffering yourself as well, since it can
take a while to generate a new view and you have to update the screen
as new chunks of image are generated.

John
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Bastien Nocera
In reply to this post by Magnus Bergman-3
On Sun, 2018-09-09 at 01:23 +0200, Magnus Bergman wrote:

> On Fri, 07 Sep 2018 12:51:32 +0200
> Bastien Nocera <[hidden email]> wrote:
>
> > > > Gegl is great for image editing. But not as much for simple
> > > > viewing.  
> > >
> > > This is debatable. If I'm viewing a 4000x4000 RGB image on a
> > > hidpi
> > > display I'm already pushing gdk-pixbuf and cairo to their limits
> > > because of the scaling factor applied to the window — not only
> > > the
> > > buffer gets loaded uncompressed to allow for zooming, but the
> > > image
> > > viewer needs to render a CPU-scaled down copy of the image.
> > >
> > > Sure, for viewing a 500x400px image macro for a meme we're fine;
> > > but
> > > we're fine with gdk-pixbuf as well, so there's really no need to
> > > change to a different image loading library.  
> >
> > I concur, 4000x4000 would likely OOM your machine, and it's not
> > really
> > fixable:
> > https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/30
> >
> > Viewers should use GEGL, and GEGL should be taught about more
> > formats.
> > That still leaves many GIF files unhandled though, and I'm not sure
> > we'd want apps writing their own GIF loader, seeing how complicated
> > that is.
>
> How do you mean it's not fixable? Of course it's not fixable that
> processing larger amounts of data will require more processing power.
> So I think it's kind of obvious that creating thumbnails for many
> large
> images will take it's time. But that shouldn't need be too much of a
> problem. Without looking too deeply into it, it looks like a problem
> with nautilus to me. Obviously it's a bad idea to to run the
> thumbnailers synchronously (which I can't imagine Nautilus does), and
> it's also bad to run too many memory hungry tasks in parallel. But
> that must be fixable, right? Like limiting the the total size in
> bytes
> of files being allowed to be processed in parallel, for example.

It's not fixable without breaking the API and ABI of gdk-pixbuf. And
nautilus doesn't thumbnail images itself (there's a thumbnailer that
gets sandboxed by the thumbnailing code), or do it synchronously (the
thumbnailers are out-of-process).

<snip>

> > >  The animation API is pretty much a garbage fire, so it may go on
> > > the chopping block as well. Of course, deprecated API will keep
> > > working as well—or as badly—as it works today, so people can
> > > still
> > > use it. Moving pixbuf loaders to separate processes, and wrap
> > > them
> > > in sandboxes, would be a fairly good thing to do; it need to be
> > > decided at run time, though, because there are many users of
> > > GdkPixbuf that already run in a sandbox, which prevents creating
> > > smaller sandboxes inside it.  
> >
> > That'd be best left to an API that can do that natively, with the
> > API
> > being thought out ahead of time.
> >
> > In the short term, my wishlist/TODO list would be:
> > - somebody writes a GIF loader that is readable, and passes the
> > test
> > suite.
>
> I've written loader for GIF that simply wraps abydos. In lines of
> code it's about a quarter the size of the current loader, even
> including
> the GIF plugin for abydos. It might even be slightly smaller with the
> whole of abydos included in the equation. On the downside it probably
> doesn't pass the test suite since I haven't tried it. But I will, and
> hopefully publish the whole thing in a couple of days.

That's unfortunately not mergeable, and unless you use a library for
your GIF plugin in abydos, would just be shifting the potential bugs to
the abydos code base.

> > - we disable every loader by default except the ones that the core
> > desktop needs
> > - image viewers that rely on gdk-pixbuf ship their additional
> > loaders
> > in the app's Flatpak[1].
>
> I don't care much for Flatpak in particular. But generalised and
> rephrased as, leave it to the distributors to decide, I agree that
> this is absolutely the best approach.

Without Flatpak, you're just removing image format support from image
viewers, as many packaging guidelines in distributions forbid the
bundling of libraries. They'd want to ship a single copy of the gdk-
pixbuf loaders, and the applications wouldn't have any protection from
files that the loaders would trip over.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Debarshi Ray-2
In reply to this post by Gtk+ - Dev - General mailing list
On Mon, Sep 10, 2018 at 09:40:13AM +0100, [hidden email] wrote:
> I make a gtk viewer that can display large images efficiently (over
> 100,000 x 100,000), linked above. I hit a few other issues:
>
> 1. You can't use a large ScrolledWindow and only paint the visible
> area, since you can easily go over the 64k pixel limit on viewports.
> You have to handle all the scrolling yourself.

Yes, the View widget needs to implement GtkScrollable, and not be one
massive GtkDrawingArea.

> 2. You need to keep all image processing in a set of background
> threads and update the display asynchronously, perhaps this is
> obvious.

I thought we were talking about a "simple" viewer. :)

Yes, if you are doing any kind of image processing, you can't let that
block the UI.

But if you are just talking about zooming in and out, then a
gegl_buffer_get() inside GtkWidget::draw isn't terrible. There are 8
mipmap levels, so your 100,000 x 100,000 image becomes 12500 x 12500.

> 3. You have to do the double-buffering yourself as well, since it can
> take a while to generate a new view and you have to update the screen
> as new chunks of image are generated.

You don't need double-buffering if you want to update the View as soon
as new chunks are generated. That's what GIMP does. You'll need it
if you want to update the entire view in one frame.

Here's a standalone widget to render a GeglNode that supports animated
zooms and double-buffered updates:
https://gitlab.gnome.org/GNOME/gnome-photos/blob/master/src/photos-image-view.c

There's also gegl-gtk, but it might be a little dusty.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Magnus Bergman-3
In reply to this post by Bastien Nocera
On Mon, 10 Sep 2018 11:31:42 +0200
Bastien Nocera <[hidden email]> wrote:

> > I've written loader for GIF that simply wraps abydos. In lines of
> > code it's about a quarter the size of the current loader, even
> > including
> > the GIF plugin for abydos. It might even be slightly smaller with
> > the whole of abydos included in the equation. On the downside it
> > probably doesn't pass the test suite since I haven't tried it. But
> > I will, and hopefully publish the whole thing in a couple of days.  
>
> That's unfortunately not mergeable, and unless you use a library for
> your GIF plugin in abydos, would just be shifting the potential bugs
> to the abydos code base.

I do use a library (or two). I've written one plugin that uses giflib
and one that uses ImageMagick. I assumed using giflib would be a
straighter path, but it wasn't. Firstly it only supports reading images
from disk (but abydos automatically creates temporary files then needed
so that didn't add any extra code at least). Secondly it doesn't do
much more than unpacking the pixels. How to interpret what comes out is
left as an exercise for the user, and requires a bit of knowledge about
the GIF formats and it's quirks. So that plugin isn't built by default.
ImageMagick on the other hand did much more to be of help, and required
far less code to use. So shifting the responsibility to ImageMagick
seems reasonable, I think.

I tested them both on all the GIF images included in the gdk-pixbuf
test suit. Both plugins mostly work, but to varying degree. The one
based on giflib segfaults with 1_partyanimsm2.gif (because the
allocation containing the pixels which giflib provides is less than the
images width x height, I haven't yet looked deeper into it). The
ImageMagick based plugin on the other doesn't crash at least, and all
the invalid images are correctly classified as invalid. The image
1_partyanimsm2.gif still shows as garbage except the first frame. The
image aero.gif has the frame delay set to zero for every frame but the
first. I'm not sure how that should be interpreted, so I simply
exchanged zero values for a small delay (0.02 seconds). I will read up
on the GIF format and hopefully get things working better.

It's available here if you want to try it out:
http://snisurset.net/code/abydos/

> > > - we disable every loader by default except the ones that the core
> > > desktop needs
> > > - image viewers that rely on gdk-pixbuf ship their additional
> > > loaders
> > > in the app's Flatpak[1].  
> >
> > I don't care much for Flatpak in particular. But generalised and
> > rephrased as, leave it to the distributors to decide, I agree that
> > this is absolutely the best approach.  
>
> Without Flatpak, you're just removing image format support from image
> viewers, as many packaging guidelines in distributions forbid the
> bundling of libraries. They'd want to ship a single copy of the gdk-
> pixbuf loaders, and the applications wouldn't have any protection from
> files that the loaders would trip over.

I'm not arguing against that. I just think it's an issue best left
entirely to distributors (including the choice between bundling and
dependencies).

How and where to implement sandboxing is an interesting question still.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Magnus Bergman-3
In reply to this post by Debarshi Ray-2
On Mon, 10 Sep 2018 07:02:23 +0000
Debarshi Ray <[hidden email]> wrote:

> On Sun, Sep 09, 2018 at 02:57:30AM +0200, Magnus Bergman wrote:
> > Many fields of science deal with images of multi
> > gigabyte sizes. Ideally any image viewer should be able to handle
> > these too with the right plugin (probably using GEGL in that case).
> > But I think the problem with large images (say 12000x12000 or so)
> > is giving it to the application as a pixmap. From my own tests it
> > seams it's fine at least as long as the images are no bigger than
> > the screen. So if the drawing (and implicitly also scaling) is
> > handed over to the loading library (which in turn might hand it
> > over to the plugin), this problem can be avoided.  
>
> Even if one does decode the entire full resolution image into a tiled
> data structure (say, GeglBuffer), there's no need to create a Cairo
> surface for the entire image at 1:1 zoom. All that's needed is a
> surface to represent the visible area at the visible zoom. That's a
> lot more manageable.

Yes, exactly. Using abydos_render() that's very possible to implement by
the back end. Then trying to view larger images using gdk-pixbuf, I
didn't experience any particular problems then the image was at normal
size or zoomed in. The problem was zooming out. So I think just
creating one or two prescaled versions will get you quite far (as long
as there is no problem fitting the image into memory that is).
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Bastien Nocera
In reply to this post by Magnus Bergman-3
On Mon, 2018-09-10 at 22:29 +0200, Magnus Bergman wrote:

> On Mon, 10 Sep 2018 11:31:42 +0200
> Bastien Nocera <[hidden email]> wrote:
>
> > > I've written loader for GIF that simply wraps abydos. In lines of
> > > code it's about a quarter the size of the current loader, even
> > > including
> > > the GIF plugin for abydos. It might even be slightly smaller with
> > > the whole of abydos included in the equation. On the downside it
> > > probably doesn't pass the test suite since I haven't tried it.
> > > But
> > > I will, and hopefully publish the whole thing in a couple of
> > > days.  
> >
> > That's unfortunately not mergeable, and unless you use a library
> > for
> > your GIF plugin in abydos, would just be shifting the potential
> > bugs
> > to the abydos code base.
>
> I do use a library (or two). I've written one plugin that uses giflib
> and one that uses ImageMagick. I assumed using giflib would be a
> straighter path, but it wasn't. Firstly it only supports reading
> images
> from disk (but abydos automatically creates temporary files then
> needed
> so that didn't add any extra code at least). Secondly it doesn't do
> much more than unpacking the pixels. How to interpret what comes out
> is
> left as an exercise for the user, and requires a bit of knowledge
> about
> the GIF formats and it's quirks. So that plugin isn't built by
> default.
> ImageMagick on the other hand did much more to be of help, and
> required
> far less code to use. So shifting the responsibility to ImageMagick
> seems reasonable, I think.

No, it really isn't:
https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html

We want to have less CVEs, not more.

> I tested them both on all the GIF images included in the gdk-pixbuf
> test suit. Both plugins mostly work, but to varying degree. The one
> based on giflib segfaults with 1_partyanimsm2.gif (because the
> allocation containing the pixels which giflib provides is less than
> the
> images width x height, I haven't yet looked deeper into it). The
> ImageMagick based plugin on the other doesn't crash at least, and all
> the invalid images are correctly classified as invalid. The image
> 1_partyanimsm2.gif still shows as garbage except the first frame. The
> image aero.gif has the frame delay set to zero for every frame but
> the
> first. I'm not sure how that should be interpreted, so I simply
> exchanged zero values for a small delay (0.02 seconds). I will read
> up
> on the GIF format and hopefully get things working better.
>
> It's available here if you want to try it out:
> http://snisurset.net/code/abydos/

Having looked at giflib, and knowing the author, the current plan still
is to have something based on libnsgif in the future.

> > > > - we disable every loader by default except the ones that the
> > > > core
> > > > desktop needs
> > > > - image viewers that rely on gdk-pixbuf ship their additional
> > > > loaders
> > > > in the app's Flatpak[1].  
> > >
> > > I don't care much for Flatpak in particular. But generalised and
> > > rephrased as, leave it to the distributors to decide, I agree
> > > that
> > > this is absolutely the best approach.  
> >
> > Without Flatpak, you're just removing image format support from
> > image
> > viewers, as many packaging guidelines in distributions forbid the
> > bundling of libraries. They'd want to ship a single copy of the
> > gdk-
> > pixbuf loaders, and the applications wouldn't have any protection
> > from
> > files that the loaders would trip over.
>
> I'm not arguing against that. I just think it's an issue best left
> entirely to distributors (including the choice between bundling and
> dependencies).
>
> How and where to implement sandboxing is an interesting question
> still.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Magnus Bergman-3
On Tue, 11 Sep 2018 00:07:27 +0200
Bastien Nocera <[hidden email]> wrote:

> On Mon, 2018-09-10 at 22:29 +0200, Magnus Bergman wrote:
> > On Mon, 10 Sep 2018 11:31:42 +0200
> > Bastien Nocera <[hidden email]> wrote:
> >  
> > I do use a library (or two). I've written one plugin that uses
> > giflib and one that uses ImageMagick. I assumed using giflib would
> > be a straighter path, but it wasn't. Firstly it only supports
> > reading images
> > from disk (but abydos automatically creates temporary files then
> > needed
> > so that didn't add any extra code at least). Secondly it doesn't do
> > much more than unpacking the pixels. How to interpret what comes out
> > is
> > left as an exercise for the user, and requires a bit of knowledge
> > about
> > the GIF formats and it's quirks. So that plugin isn't built by
> > default.
> > ImageMagick on the other hand did much more to be of help, and
> > required
> > far less code to use. So shifting the responsibility to ImageMagick
> > seems reasonable, I think.  
>
> No, it really isn't:
> https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html
>
> We want to have less CVEs, not more.

I see what you mean. A few of them (although none of the more serious
ones) were even related to the GIF loader specifically. But the sheer
volume kind of speaks for itself otherwise. :(

> > I tested them both on all the GIF images included in the gdk-pixbuf
> > test suit. Both plugins mostly work, but to varying degree. The one
> > based on giflib segfaults with 1_partyanimsm2.gif (because the
> > allocation containing the pixels which giflib provides is less than
> > the
> > images width x height, I haven't yet looked deeper into it). The
> > ImageMagick based plugin on the other doesn't crash at least, and
> > all the invalid images are correctly classified as invalid. The
> > image 1_partyanimsm2.gif still shows as garbage except the first
> > frame. The image aero.gif has the frame delay set to zero for every
> > frame but the
> > first. I'm not sure how that should be interpreted, so I simply
> > exchanged zero values for a small delay (0.02 seconds). I will read
> > up
> > on the GIF format and hopefully get things working better.
> >
> > It's available here if you want to try it out:
> > http://snisurset.net/code/abydos/ 
>
> Having looked at giflib, and knowing the author, the current plan
> still is to have something based on libnsgif in the future.

I guess I'll write a third GIF plugin based libnsgif then.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Gtk+ - Dev - General mailing list
On Tue, 11 Sep 2018 at 03:11, Magnus Bergman
<[hidden email]> wrote:

> On Tue, 11 Sep 2018 00:07:27 +0200
> Bastien Nocera <[hidden email]> wrote:
> > No, it really isn't:
> > https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html
> >
> > We want to have less CVEs, not more.
>
> I see what you mean. A few of them (although none of the more serious
> ones) were even related to the GIF loader specifically. But the sheer
> volume kind of speaks for itself otherwise. :(

IM joined Google's OSS-Fuzz programme last year:

https://github.com/google/oss-fuzz

The huge surge in CVEs was caused by that --- they've been fixing one
or two a day ever since. Once they are through this very painful
process, IM ought to be rather safe.

I do agree though that it's a large and complex thing to use for such
a (relatively) simple task.

John
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Bastien Nocera
On Tue, 2018-09-11 at 07:40 +0100, John Cupitt via gtk-devel-list
wrote:
> On Tue, 11 Sep 2018 at 03:11, Magnus Bergman
> <[hidden email]> wrote:
> > On Tue, 11 Sep 2018 00:07:27 +0200
> > Bastien Nocera <[hidden email]> wrote:
> > > No, it really isn't:
> > >
https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html

> > >
> > > We want to have less CVEs, not more.
> >
> > I see what you mean. A few of them (although none of the more
> > serious
> > ones) were even related to the GIF loader specifically. But the
> > sheer
> > volume kind of speaks for itself otherwise. :(
>
> IM joined Google's OSS-Fuzz programme last year:
>
> https://github.com/google/oss-fuzz
>
> The huge surge in CVEs was caused by that --- they've been fixing one
> or two a day ever since. Once they are through this very painful
> process, IM ought to be rather safe.
>
> I do agree though that it's a large and complex thing to use for such
> a (relatively) simple task.

I maintained ImageMagick in RHEL a long time ago, it was already that
way though security issues cropped up a bit less often than every day
(!). I don't see any reason for us to want to us it.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Magnus Bergman-3
On Tue, 11 Sep 2018 13:22:17 +0200
Bastien Nocera <[hidden email]> wrote:

> On Tue, 2018-09-11 at 07:40 +0100, John Cupitt via gtk-devel-list
> wrote:
> > On Tue, 11 Sep 2018 at 03:11, Magnus Bergman
> > <[hidden email]> wrote:  
> > > On Tue, 11 Sep 2018 00:07:27 +0200
> > > Bastien Nocera <[hidden email]> wrote:  
> > > > No, it really isn't:
> > > >  
> https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html
> > > >
> > > > We want to have less CVEs, not more.  
> > >
> > > I see what you mean. A few of them (although none of the more
> > > serious
> > > ones) were even related to the GIF loader specifically. But the
> > > sheer
> > > volume kind of speaks for itself otherwise. :(  
> >
> > IM joined Google's OSS-Fuzz programme last year:
> >
> > https://github.com/google/oss-fuzz
> >
> > The huge surge in CVEs was caused by that --- they've been fixing
> > one or two a day ever since. Once they are through this very painful
> > process, IM ought to be rather safe.
> >
> > I do agree though that it's a large and complex thing to use for
> > such a (relatively) simple task.  
>
> I maintained ImageMagick in RHEL a long time ago, it was already that
> way though security issues cropped up a bit less often than every day
> (!). I don't see any reason for us to want to us it.

Understandable. Anyway, I made a third GIF loader based on libnsgif
and released it. This one also handles all images in the test suit and
displays 1_partyanimsm2.gif nicely too (before I even found something
that could view it I wasn't sure if it was supposed to show garbage or
not). Since libnsgif is very straight forward to use I guess you prefer
to write your own loader instead of having abydos in the middle. If
you don't already know the API of libnsgif (it lacks documentation) it
is probably very easy to get started by porting the abydos plugin to
gdk-pixbuf. And here are some tips about things you might want to
implement differently:

The pixel format libnsgif uses happens to be the same as for gdk-pixbuf
(both for big and little endian). This means that the bitmap_create
callback can be used to create a GdkPixbuf and bítmap_get_buffer to
return the pixels of the GdkPixbuf, so libnsgif can draw directly into
it. However this assumes that the rowstride equals the width (which I
guess is a valid assumption for RGBA). It would be easy just returning
a copy of this GdkPixbuf then requested and use gif_decode_frame() to
change the frame then needed (obviously using locking since several
independent GdkPixbufAnimationIter could theoretically be used at the
same time even if it's a highly unlikely use case). This will possibly
make it even simpler and more readable than the approach I took with
the abydos loader. The reason I chose to decode all frames directly
upon load and then throw away the gif_animation was manly because the
conversion of abydos doesn't require the pixels to be copied. Also note
that progressive loading is supported by libnsgif, but instead of just
feeding it the new bytes, it needs a buffer containing all the previous
bytes as well. And you probably want to add support for (netscape
style) looping, which is something abydos doesn't support yet.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

John Emmas-2
Sorry, I haven't been following this conversation but as a side-issue...
I only noticed this morning that gdk-pixbuf doesn't seem to be able to
load TIF images any more.  I've attached a small file that won't load
but I haven't managed to load any TIF image from the ones I've tested
this morning.

If someone's got a few spare minutes, could they try loading the
attached image using 'gdk_pixbuf_new_from_file()' and just let me know
if it works?  I'm sure this always worked for me in the past... :-(

John

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

BlueUpdate.tif (41K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Magnus Bergman-3
On Sat, 15 Sep 2018 09:47:33 +0100
John Emmas <[hidden email]> wrote:

> Sorry, I haven't been following this conversation but as a
> side-issue... I only noticed this morning that gdk-pixbuf doesn't
> seem to be able to load TIF images any more.  I've attached a small
> file that won't load but I haven't managed to load any TIF image from
> the ones I've tested this morning.
>
> If someone's got a few spare minutes, could they try loading the
> attached image using 'gdk_pixbuf_new_from_file()' and just let me
> know if it works?  I'm sure this always worked for me in the
> past... :-(

The loader hasn't been removed from gdk-pixbuf so it should work. What
you can do to trouble shoot is to run gdk-pixbuf-query-loaders and see
if the TIFF loader is included. You may notice some information about
the it and why it can't load. Some mismatch in versions of libtiff
could for example be a reason. Otherwise you should probably file a bug
report with more information (perhaps to your distribution firstly).
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

John Emmas-2
On 15/09/2018 12:07, Magnus Bergman wrote:
> Some mismatch in versions of libtiff
> could for example be a reason. Otherwise you should probably file a bug
> report with more information (perhaps to your distribution firstly).
>

Thanks Magnus.  I've a feeling that the problem might come down to
struct alignment.  Although I'm building on Windows, I currently compile
both tiff and gdk-pixbuf with 1-byte struct alignment which seems to
work for png / jpeg etc.  But maybe tiff expects 8-byte alignment?

Do you happen to know if the tiff library has its own mailing list? I
haven't had much success in finding one....

John

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

John Emmas-2
On 15/09/2018 18:48, John Emmas wrote:
>
> Thanks Magnus.  I've a feeling that the problem might come down to
> struct alignment.
>

No, I was wrong about that.  I've tracked the problem to commit
#ce52cefbbc in gdk-pixbuf (which brings me to the 2nd problem...)


On 15/09/2018 18:48, John Emmas wrote:
>
> Do you happen to know if the tiff library has its own mailing list? I
> haven't had much success in finding one....
>

In fact I'll need the mailing list for gdk-pixbuf now - except that I
can't find that one either!! (or is this the correct place for reporting
gdk-pixbuf issues?)

John
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Gtk+ - Dev - General mailing list
On Sun, 16 Sep 2018 at 10:47, John Emmas <[hidden email]> wrote:
On 15/09/2018 18:48, John Emmas wrote:
>
> Do you happen to know if the tiff library has its own mailing list? I
> haven't had much success in finding one....
>

In fact I'll need the mailing list for gdk-pixbuf now - except that I
can't find that one either!! (or is this the correct place for reporting
gdk-pixbuf issues?)


The correct way to report issues for gdk-pixbuf:

2. do not attach to an existing, unrelated thread on a mailing list; create a new topic instead

For discussions, you can use this mailing list—but issues should strictly be reported on the issue tracker.

Ciao,
 Emmanuele.

--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

John Emmas-2
On 16/09/2018 11:18, Emmanuele Bassi wrote:
>
> The correct way to report issues for gdk-pixbuf:
>
> 1. use the issue tracker:
> https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/new
>

Thanks Emmanuele - done!
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: An alternative to gdk-pixbuf

Gtk+ - Dev - General mailing list
In reply to this post by John Emmas-2
On 09/15/18 10:48 AM, John Emmas wrote:
> On 15/09/2018 12:07, Magnus Bergman wrote:
>> Some mismatch in versions of libtiff
>> could for example be a reason. Otherwise you should probably file a bug
>> report with more information (perhaps to your distribution firstly).
>>
>
> Do you happen to know if the tiff library has its own mailing list? I haven't
> had much success in finding one....

Yes - see http://www.simplesystems.org/libtiff/ for info on the list.

--
        -Alan Coopersmith-               [hidden email]
         Oracle Solaris Engineering - https://blogs.oracle.com/alanc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
12