Please do. libjasper requires a lot of security patch maintenance while OpenJPEG is actively under development.

What's more likely to happen is the JPEG2000 loader being removed altogether though.

Given that JPEG2000 files are usually pretty huge, and that gdk-pixbuf is pretty badly suited to loading those types of files, for me the way to fix this problem would be:
- add a thumbnailer in gegl, or in a third-party repository, that would use gegl to create thumbnails for those sorts of huge files
- add a JPEG2000 loader in gegl based on OpenJPEG instead (it already has one based on libjasper)
- remove the jp2 loader in gdk-pixbuf

Rinse and repeat for TIFF.

The GEGL loaders don't have a typical GIO-like GCancellable driven asynchronous API. At the moment, the only way to use them it use it via a GEGL graph that is processed with gegl_node_process [1]. Even if it might appear that GeglProcessor will allow you to process the graph in smaller pieces, it isn't always the case. The loaders will load and decode the file in its entirety in one shot.

Plus, the GEGL loaders don't have little things like applying the embedded orientation.

Therefore, I don't think the GEGL loaders are ready to completely replace the ones in GdkPixbuf. Maybe we should start by adding some API that looks a lot like the gdk_pixbuf_new_from_* functions but gives a GeglBuffer, instead of a GdkPixbuf?

Turning a GeglBuffer to a GdkPixbuf for existing applications should be quite easy. See the gegl:save-pixbuf operation for a possible implementation.

[1] http://www.gegl.org/api.html

yes, removing the jp2000 loader gets a +1 from me

(In reply to Debarshi Ray from comment #4)
> The GEGL loaders don't have a typical GIO-like GCancellable driven
> asynchronous API. At the moment, the only way to use them it use it via a
> GEGL graph that is processed with gegl_node_process [1]. Even if it might
> appear that GeglProcessor will allow you to process the graph in smaller
> pieces, it isn't always the case. The loaders will load and decode the file
> in its entirety in one shot.
> 
> Plus, the GEGL loaders don't have little things like applying the embedded
> orientation.

We can always add that to GEGL eventually.

> Therefore, I don't think the GEGL loaders are ready to completely replace
> the ones in GdkPixbuf.

I didn't talk about replacing gdk-pixbuf with Gegl for SVG, or PNG, or any of those other types of images. I'm specifically talking of JPEG2000 and TIFF, both of which have problems handling huge files.

> Maybe we should start by adding some API that looks a
> lot like the gdk_pixbuf_new_from_* functions but gives a GeglBuffer, instead
> of a GdkPixbuf?

No, because we'd get the same problem back. We *do not* want a GdkPixbuf, because for a 20k x 20k b&w image, we'd be using more than a gig of RAM with GdkPixbuf, whereas gegl would keep it in the same colourspace, reducing its in-RAM size greatly.

See bug 666391.

(In reply to Bastien Nocera from comment #6)
> (In reply to Debarshi Ray from comment #4)
> > The GEGL loaders don't have a typical GIO-like GCancellable driven
> > asynchronous API. At the moment, the only way to use them it use it via a
> > GEGL graph that is processed with gegl_node_process [1]. Even if it might
> > appear that GeglProcessor will allow you to process the graph in smaller
> > pieces, it isn't always the case. The loaders will load and decode the file
> > in its entirety in one shot.
> > 
> > Plus, the GEGL loaders don't have little things like applying the embedded
> > orientation.

Also, the bit about GdkPixbuf being able to use a scale factor to directly downscale when loading. It can be a significant win in certain cases, and is missing in GEGL.

Then colour management. It is pretty straightforward with GdkPixbuf as compared to GEGL.

None of these are unsolvable problems, but taken together they do present a significant obstacle for an application.

> We can always add that to GEGL eventually.

Eventually ... :)

As someone who is writing a non-trivial application based on GEGL, I have been trying to convince people about the need for such an API. If we think that we are going encourage more people to use GEGL, then maybe we should take this up more seriously.

Note that even GIMP master/2.9.x doesn't use GEGL's loaders. It continues to use its own which have certain niceties (like applying embedded orientation) that are missing from the ones in GEGL.

> > Therefore, I don't think the GEGL loaders are ready to completely replace
> > the ones in GdkPixbuf.
> 
> I didn't talk about replacing gdk-pixbuf with Gegl for SVG, or PNG, or any
> of those other types of images. I'm specifically talking of JPEG2000 and
> TIFF, both of which have problems handling huge files.

It is problematic for applications like Eye of GNOME which rely on GdkPixbuf for the loading. (Doesn't shotwell do the same?) Those applications will now need something else to load those kinds of images.

If that "something else" is going to be GEGL then they would run into all the above problems.

> > Maybe we should start by adding some API that looks a
> > lot like the gdk_pixbuf_new_from_* functions but gives a GeglBuffer, instead
> > of a GdkPixbuf?
> 
> No, because we'd get the same problem back. We *do not* want a GdkPixbuf,

Did I say GdkPixbuf? I said *GeglBuffer*. :)

> because for a 20k x 20k b&w image, we'd be using more than a gig of RAM with
> GdkPixbuf, whereas gegl would keep it in the same colourspace, reducing its
> in-RAM size greatly.

(While GEGL (through Babl) knows a lot more about colour spaces than GdkPixbuf, its ability to handle larger than RAM images is more due to the tiling in GeglBuffers than colour space optimizations.)

JasPer looks actively maintained again https://github.com/mdadams/jasper

Let's consider this fixed, whatever the status of loading huge images with GdkPixbuf.