dallasgroot/Gimp
dallasgroot/Gimp
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Gimp/libgimp/gimpdrawablecolor_pdb.h

124 lines
7 KiB
C
Raw Permalink Normal View History

app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
/* LIBGIMP - The GIMP Library
* Copyright (C) 1995-2003 Peter Mattis and Spencer Kimball
*
* gimpdrawablecolor_pdb.h
*
* This library is free software: you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 3 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
Change the license URL from http://www.gnu.org/licenses/ to https://
2018-07-11 14:27:07 -07:00
* <https://www.gnu.org/licenses/>.
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
*/
/* NOTE: This file is auto-generated by pdbgen.pl */
#if !defined (__GIMP_H_INSIDE__) && !defined (GIMP_COMPILATION)
#error "Only <libgimp/gimp.h> can be included directly."
#endif
Revert (partly) "app, pdb, libgimp: use "#pragma once" instead of:" This reverts commit 246f9d284f0a60053eed70c23c2bf9080e2f1b15. This only reverts the part modifying libgimp* headers. All the part switching to #pragma once in app/ was kept. See #14668.
2025-08-13 15:31:46 -07:00
#ifndef __GIMP_DRAWABLE_COLOR_PDB_H__
#define __GIMP_DRAWABLE_COLOR_PDB_H__
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
G_BEGIN_DECLS
/* For information look into the C source or the html documentation */
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(gimp:brightness_contrast)
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_brightness_contrast (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
gdouble brightness,
gdouble contrast);
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(gimp:color_balance)
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_color_balance (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
GimpTransferMode transfer_mode,
gboolean preserve_lum,
gdouble cyan_red,
gdouble magenta_green,
gdouble yellow_blue);
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(gimp:colorize)
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_colorize_hsl (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
gdouble hue,
gdouble saturation,
gdouble lightness);
Issue #15681: deprecate gimp_drawable_curves_explicit() and… … gimp_drawable_curves_spline(). We can now run directly "gimp:curves" operation, both destructively or non-destructively, but also setting the TRC, as well as individual point types (when the curve is of type "smooth" instead of freehand). This is much more powerful!
2026-03-01 12:48:13 -08:00
GIMP_DEPRECATED_FOR(gimp:curves)
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_curves_explicit (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
GimpHistogramChannel channel,
app, libgimp, pdb: fix other int sizes. Avoid the stack smashing bug from yesterday in other functions. Additionally to fixing other functions, do not cast the pointer to size in the PDB generation scripts so that we can quickly spot such bugs in the future, through compilation time warnings, instead of hiding them.
2024-10-28 02:46:17 -07:00
gsize num_values,
libgimp, pdb: port gimp_drawable_curves_explicit,spline() to double and deprecate gimp_curves_explicit,spline().
2014-06-17 13:37:46 -07:00
const gdouble *values);
Issue #15681: deprecate gimp_drawable_curves_explicit() and… … gimp_drawable_curves_spline(). We can now run directly "gimp:curves" operation, both destructively or non-destructively, but also setting the TRC, as well as individual point types (when the curve is of type "smooth" instead of freehand). This is much more powerful!
2026-03-01 12:48:13 -08:00
GIMP_DEPRECATED_FOR(gimp:curves)
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_curves_spline (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
GimpHistogramChannel channel,
app, libgimp, pdb: improve a bit the docs of gimp_drawable_curves_spline(). One point which was raised in #15681 is that the documentation is lacking. * Let's write down that the range of the point coordinates is in the [0, 1] range. * Also let's rename num_points to num_coordinates because argument points will actually contain 2 coordinates per points (so for 10 points, the points array will be of size 20). We also write that it means that num_coordinates must therefore be even. * Add more spacing in the docs and some better styling and annotations.
2026-01-27 11:42:08 -08:00
gsize num_coordinates,
libgimp, pdb: port gimp_drawable_curves_explicit,spline() to double and deprecate gimp_curves_explicit,spline().
2014-06-17 13:37:46 -07:00
const gdouble *points);
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(gegl:component_extract)
pdb: add a PDB procedure for extract-component (cherry picked from commit dbf9f277a231cb2b2109fce6490b483b0464abab) Committer's (Jehan) updates: - Component type is now int32 (int8 is not a PDB type available anymore). - PDB files re-generated to handle changes in API and types.
2021-05-12 03:08:02 -07:00
gboolean gimp_drawable_extract_component (GimpDrawable *drawable,
gint component,
gboolean invert,
gboolean linear);
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(gimp:desaturate)
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_desaturate (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
GimpDesaturateMode desaturate_mode);
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_equalize (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
gboolean mask_only);
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_histogram (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
GimpHistogramChannel channel,
pdb, app, libgimp: change ranges for histogram and threshold to 0.0..1.0 They used to be 0..255, inherited from the old gimp_histogram() and gimp_threshold() procedures. This commit deprecates these old procedures and changes the ranges in the new gimp_drawable_histogram() and gimp_drawable_threshold() to double with a 0.0..1.0 range.
2016-11-01 12:46:31 -07:00
gdouble start_range,
gdouble end_range,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
gdouble *mean,
gdouble *std_dev,
gdouble *median,
gdouble *pixels,
gdouble *count,
gdouble *percentile);
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(gimp:hue_saturation)
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_hue_saturation (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
GimpHueRange hue_range,
gdouble hue_offset,
gdouble lightness,
gdouble saturation,
gdouble overlap);
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(filters "gegl:invert_linear" or "gegl:invert_gamma")
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_invert (GimpDrawable *drawable,
pdb, libgimp: change the gimp-drawable-invert API again Remove the invert-linear and invert-non-linear variants and simply add "gboolean linear" to gimp-drawable-invert. This should actually be an enum but I didn't find a good name right now...
2017-09-03 12:28:47 -07:00
gboolean linear);
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(gimp:levels)
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_levels (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
GimpHistogramChannel channel,
gdouble low_input,
gdouble high_input,
Bug 762443 - Levels tool Output Level sliders works incorrectly Add "clamp-input" (which clamps the input values to [0..1]) and "clamp-output" (which clips the final result to [0..1]), properties, parameters and GUI to: - GimpLevelsConfig - GimpOperationLevels - The levels tool dialog - The gimp_drawable_levels() PDB API The old deprecated gimp_levels() PDB API now sets both clamping options to TRUE which restores the 2.8 behavior. Also reorder some stuff in GimpLevelsConfig and elsewhere so the levels parameters are always in the same order.
2018-01-02 09:42:21 -08:00
gboolean clamp_input,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
gdouble gamma,
gdouble low_output,
Bug 762443 - Levels tool Output Level sliders works incorrectly Add "clamp-input" (which clamps the input values to [0..1]) and "clamp-output" (which clips the final result to [0..1]), properties, parameters and GUI to: - GimpLevelsConfig - GimpOperationLevels - The levels tool dialog - The gimp_drawable_levels() PDB API The old deprecated gimp_levels() PDB API now sets both clamping options to TRUE which restores the 2.8 behavior. Also reorder some stuff in GimpLevelsConfig and elsewhere so the levels parameters are always in the same order.
2018-01-02 09:42:21 -08:00
gdouble high_output,
gboolean clamp_output);
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_levels_stretch (GimpDrawable *drawable);
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(gegl:shadows_highlights)
pdb: add a PDB procedure for shadows-highlights (cherry picked from commit 0b96363e107e0c550d1fa7995939b66813c747c9) Reviewer's (Jehan) note: the generated source files were re-generated and amended in this commit.
2021-05-12 05:09:25 -07:00
gboolean gimp_drawable_shadows_highlights (GimpDrawable *drawable,
gdouble shadows,
gdouble highlights,
gdouble whitepoint,
gdouble radius,
gdouble compress,
gdouble shadows_ccorrect,
gdouble highlights_ccorrect);
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(gimp:posterize)
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_posterize (GimpDrawable *drawable,
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
gint levels);
app, libgimp, pdb: deprecate various procedures in favor of filters. I have manually tested each and every of the deprecated functions, making sure we don't lose any feature. As expected, we don't. Having dedicated libgimp functions may feel a tiny bit easier to call but this is not scalable. We can't do this forever, with one function per filter. And fortunately we won't have to, since now we can call filters on any drawable directly! It also comes with the following generic advantages: * It works with any filter, even third-party ones; * We can also append filters non-destructively for later removal or edits (the deprecated functions were always merging the filters); * If the filter evolves, e.g. with new arguments, it should not affect the API (though we should implement GEGL operation versions); * If we don't need to set all arguments (e.g. leaving many args with default value), the filter API may even be simpler and shorter; * The filter API will be much less "opaque" thanks to argument naming (rather than a long list of integers, doubles, etc.). Specifically to the now deprecated functions, I noted the following weaknesses on the deprecated API when testing: * gimp_drawable_colorize_hsl() was missing a "color" argument; * gimp_drawable_extract_component() had the enum argument "component" set as an integer, which is particularly opaque when re-reading existing code. Whereas the filter API uses generate choice strings which are self-explanatory! For instance choice RGB Red is 0 with the deprecated function but "rgb-r" with the filter API. * gimp_drawable_levels() was missing "trc" argument (as noted in #15681). And as expected, no features are lost. Note that I didn't deprecate the curves functions yet, because we need to implement the GimpCurve type in libgimp first. There are a few more functions which I didn't deprecate yet, because they don't use a filter directly, but some core functions, though for some of them, it is very likely they can be efficiently reimplemented with the filter API too. I'll have to look closer at it. It looks like we may have to implement GimpHistogram in libgimp too though.
2026-02-01 13:06:10 -08:00
GIMP_DEPRECATED_FOR(gimp:threshold)
libgimp, pdb: add GimpItem > GimpDrawable > GimpLayer classes. Only class and subclasses creation and PDB generation for this first step. I'll later do other types of items.
2019-08-13 04:59:33 -07:00
gboolean gimp_drawable_threshold (GimpDrawable *drawable,
app, pdb, libgimp: allow to choose the channel when thresholding so the threshold can now be based on the GimpHistogramChannel enum. Add a channel menu to the threshold dialog and a channel argument to the PDB procedure (which is new in 2.10). If I hadn't forgotten what the "RGB" channel is supposed to do I would have implemented the RGB mode in GimpOperationThreshold correctly. Right now I'm just guessing. Anyone?
2016-11-01 14:41:56 -07:00
GimpHistogramChannel channel,
pdb, app, libgimp: change ranges for histogram and threshold to 0.0..1.0 They used to be 0..255, inherited from the old gimp_histogram() and gimp_threshold() procedures. This commit deprecates these old procedures and changes the ranges in the new gimp_drawable_histogram() and gimp_drawable_threshold() to double with a 0.0..1.0 range.
2016-11-01 12:46:31 -07:00
gdouble low_threshold,
gdouble high_threshold);
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
Revert (partly) "app, pdb, libgimp: use "#pragma once" instead of:" This reverts commit 246f9d284f0a60053eed70c23c2bf9080e2f1b15. This only reverts the part modifying libgimp* headers. All the part switching to #pragma once in app/ was kept. See #14668.
2025-08-13 15:31:46 -07:00
app,libgimp,pdb: add a "drawable_color" PDB group Which contains all the API from the "color" group, but with a gimp_drawable namespace and with support for high bit depths. The group is actually a copy of "color" with cruft removed and some API ported to using float instead of integer API. Deprecated all "color" functions that already have a ported version in "drawable_color". This is unfinished WIP, some functions in "drawable_color" still have the old API.
2014-01-12 13:11:15 -08:00
G_END_DECLS
Revert (partly) "app, pdb, libgimp: use "#pragma once" instead of:" This reverts commit 246f9d284f0a60053eed70c23c2bf9080e2f1b15. This only reverts the part modifying libgimp* headers. All the part switching to #pragma once in app/ was kept. See #14668.
2025-08-13 15:31:46 -07:00
#endif /* __GIMP_DRAWABLE_COLOR_PDB_H__ */
Reference in a new issue Copy permalink