Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise



On Tue, Oct 7, 2014 at 8:13 PM, scl <scl gplus gmail com> wrote:
On  4.10.2014 at 5:59 PM Øyvind Kolås wrote:

Almost, developers decide which pixelformat is appropriate for their
operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale
formats as well as formats used with digital video with different data
types; currently the set of babl formats.

perhaps I missed or forgot something: what happens if a GEGL operation
is called with a wrong pixel format - will the operation refuse to work
or the data be converted to an appropriate format?

tl;dr: converted to an appropriate format.

The operations provide a hint to GEGL about the format it is going to
do read-requests with in :prepare() . GEGL does not need to abide by
this request though; and will most of the time just pass the
GeglBuffer on. Then in process() when the operation is actually
reading data (when a copy from the tiled data structure in the buffer
is made linear (or a direct peek at the data in the cases where
formats; tiles and more align perfectly)) babl_process() ends up being
called behind the scenes with the buffers format as the source format
argument and the operations requested format for the pixels as the
target format argument. Since all buffers have a babl_format, the data
will be converted, if the format is an anonymous n-component format,
the components will be type converted blindly.

Since the preceding operation specifies which format it is going to
want a GeglBuffer for writing data into. An operation can request
already in the prepare stage what formats it's sources will be
providing data in, this is already used in some places and can be used
for instance for adding 8bit and 16bit fast paths. This mechanism can
also be used to treat multiple formats the same (passing them on with
their original format.). That way some ops could be made into
no-conversion ops by treating different formats that both are linear
like for instance babl_format("RGBA float") and an imagined
babl_format("target:RGBA float") to both be treated the same. The same
way that an op just doing multiplication in the temperature analogy
can treat T and C the same in its computation, because they are both
linear - and they have the same 0.0.

/Ø


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