[Gimp-developer] Specifying chromaticities alongside gegl buffer data

Hi all

In the babl roadmap, there is the suggestion of a
babl_define_named_rgb_space() proto that takes the chromaticities to
create a babl format. This looks like a good idea, but I have a couple
of questions regarding it:

1. A GIMP plug-in's address space is different from the GIMP host
application's. After a file plug-in is done reading data into the app,
it is terminated. If a babl format is created using a function such as
above, how will a plug-in be able to pass a buffer to the host app, so
that the buffer's format in the host app has corresponding
chromaticities to what the plug-in had?

2. Assuming that processing operations want to work with buffers with
known input formats and return a buffer with a known output format, do
all such formats with custom chromaticities require naming? Would it not
be sufficient if babl knew that the buffer was in an anonymous format
with these associated chromaticities and knew how to convert it to a
well-known format that a processing op would request (such as "RGB
float")? i.e., the format is never looked up by name once it is created.

These questions rise out of the OpenEXR format that Houz and I were
looking at this week. There doesn't seem to be a way to pass the
original source data as it exists in the EXR file and associated
chromaticities from the plug-in to the GIMP app.

(The GIMP app could repeat creating a babl format in the host app for
 the plug-in by having the plug-in pass the chromaticities using
 libgimp* function calls, but there should be a way to avoid having the
 plug-in repeat itself. Rather than calling babl directly, perhaps it
 may have to create a babl format using libgimp.)


Attachment: pgpq9iaQCVj3w.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]