RSS/Atom feed Twitter
Site is read-only, email is disabled

Higher-bit depth and plug-in filters.

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

3 of 4 messages available
Toggle history

Please log in to manage your subscriptions.

Higher-bit depth and plug-in filters. Øyvind Kolås 18 Nov 12:05
  Higher-bit depth and plug-in filters. Sven Neumann 18 Nov 23:22
014201c9499f$ef788310$ce698... 07 Oct 20:27
  Higher-bit depth and plug-in filters. Øyvind Kolås 18 Nov 22:03
Øyvind Kolås
2008-11-18 12:05:23 UTC (about 16 years ago)

Higher-bit depth and plug-in filters.

On Mon, Nov 17, 2008 at 7:31 PM, Martin Nordholts 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.

Øyvind Kolås
2008-11-18 22:03:34 UTC (about 16 years ago)

Higher-bit depth and plug-in filters.

On Tue, Nov 18, 2008 at 5:06 PM, Austin Donnelly -- yahoo 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.

Sven Neumann
2008-11-18 23:22:03 UTC (about 16 years ago)

Higher-bit depth and plug-in filters.

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