Higher-bit depth and plug-in filters.

On Mon, Nov 17, 2008 at 7:31 PM, Martin Nordholts <enselic@gmail.com> wrote:
> 1. Extend the plug-in API to deal with high bit-depth images

What needs to be done is to get rid of, or stop relying on all the
existing GIMP plug-ins that change image data (the ones changing image
structure by rearranging layers, layer masks etc and in other ways
change the state of GIMP are in a different category and are valid.
But these plug-ins should not care about the datas bit-depth). We
might need a way to specify GUIs / dialogs for GEGL operations but I
do not see how GIMP plug-ins should need to deal with higher bit-depth
data.

For some legacy third-party plug-ins a GIMP legacy plug-in GEGL
operation wrapper could be created. In the future the only API to care
about if you want to modify actual pixels in an image should be the
GEGL operation API. GEGL operations should be inserted into the layer
list (work on this could probably start before the real switch, making
the filters be no-ops in the non GEGL-projection case).

If a user really wants to destructively modify a layer it would be
achieved by merging the filter layer with the buffer containing the
raw pixel data.

/Øyvind K.

On Tue, Nov 18, 2008 at 5:06 PM, Austin Donnelly -- yahoo
<austin_donnelly@yahoo.co.uk> wrote:
> Hmm, so how would a filter like Newsprint work in the GEGL framework?

User experience (accuracy might vary):
=============================

The user might want to newsprint the full layer stack of the implicit
layer group that the image itself is (The image is a collection/group
of layers). Or the user might want to newsprintify an individual layer
in this layer or one of the children of a layer group in the image.

User says: "layer-select image"

The top-most layer in the image compositing stack is selected (if a
different layer was selected the layer dialog would expand the parent
groups it belongs in and scroll to the correct position.)

User says: "add-operation newsprint"

A newsprint filter is added as a filter at the end of the toplevel
layer stack. It starts rendering the result immediately to the image
and if the user is satisfied with the results he is done. (He could
now merge the effect down if the layer below was a pure raster layer
to achieve destructive image editing, but to get a flattened image
most people would export to png, jpg tif or similar.)

The newsprint filter is the active filter/transform/effect applied to
the currently selected layer. This means that a property pane
somewhere, kind of like the tool options would allow control over
Input SPI, Output LPI, Cell Size, plates, spot function etc. Perhaps
even the controls for setting the angle per channel can be manipulated
directly in place on the canvas (a bit far fetched, but useful for
other things.)

Developer experience:
================

The function currently called newsprint() becomes the process()
implementation for a subclass of GeglOperationAreaFilter[1], since the
operation needs a constant neighbourhood around each source pixel
depending onthe oversampling used.
.
This is done by copying for instance box-blur.c[2] to newsprint.c and
replacing all references to box-blur with newsprint.

Then type make && sudo make install in this directory as the new .c
file is automatically added to the build.

Now replace the chanted arguments at the top of the file with the
parameters for newsprint, as well as replacing the process function.
Now replace the geometry setup done in prepare with something that
indicates the number of pixels needed to be provided to our
area-operation at the left, right top and bottom sides of our source
pixel. As well as specify the format we want the data in.

When this is done GEGL can use this operation like any other
operation, in XML, Python, Ruby, C, C#, the GIMP GEGL tool and other
software using GEGL and with live preview as a layer effect, etc.

(accuracy starts varying again:)
Optional: add a custom GUI control mechanism that provides controls
for editing the parameters of the new GeglOperation, (default ones
with sliders/entries/color pickers/font choosers/file pickers can be
provided by the core during development and for simple dialogs). To
reproduce a user experience similar to the existing one you would have
to create a custom dialog to get the groupings, radio buttons and tabs
for the different channels and preview for the spot functions. For
some other operations it would also be useful to add callbacks for
handling tweaking of some on image parameters for newsprint controls
for setting the angle per channel could be added. Other ops such as
iwarp have a much larger need for such hooks.

At some later point additional logic to render at power of two halving
factors from lower resolution source data might be added to support
live previews on large images (operating on mipmap levels of the
caches for nodes in the graph).

1: http://gegl.org/gegl-operation-filter.h.html
2: http://svn.gnome.org/viewvc/gegl/trunk/operations/common/box-blur.c?view=markup

Hope this helps, happy hacking.

/Øyvind K.

Hi,

On Tue, 2008-11-18 at 11:05 +0000, Øyvind Kolås wrote:

> What needs to be done is to get rid of, or stop relying on all the
> existing GIMP plug-ins that change image data (the ones changing image
> structure by rearranging layers, layer masks etc and in other ways
> change the state of GIMP are in a different category and are valid.
> But these plug-ins should not care about the datas bit-depth). We
> might need a way to specify GUIs / dialogs for GEGL operations but I
> do not see how GIMP plug-ins should need to deal with higher bit-depth
> data.

As a way to migrate plug-ins, we could add a plug-in API to libgimp that
allows plug-ins to do their pixel manipulation in terms of GEGL API.
That would turn plug-ins into a GEGL operation that uses the GIMP
plug-in infrastructure for registration and for the user interface.


Sven