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.)
Mukund
Attachment:
pgpq9iaQCVj3w.pgp
Description: PGP signature