eUgEntOptIc44/gimp
1
1
Fork 0
mirror of https://gitlab.gnome.org/GNOME/gimp.git synced 2025-10-06 09:32:41 +02:00
Code Issues Releases Activity
Files
master
gimp/app/core/gimpimage-convert-precision.c

231 lines
7.4 KiB
C
Raw Permalink Normal View History

app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* gimpimage-convert-precision.c
* Copyright (C) 2012 Michael Natterer <mitch@gimp.org>
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program 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 General Public License for more details.
*
* You should have received a copy of the GNU General Public License
Change the license URL from http://www.gnu.org/licenses/ to https://
2018-07-11 23:27:07 +02:00
* along with this program. If not, see <https://www.gnu.org/licenses/>.
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
*/
#include "config.h"
Bug 751553 - Linear precision doesn't display the image correctly When converting and image with a color profileimage between linear and gamma, create a new profile using the new API in GimpColorProfile, convert the layers to that profile and tag the image with the new profile. If creating a new profile fails, convert to the right builtin profile (linear rgb or sRGB from GimpColorProfile), but that code should be considered a fallback that will be prevented from happening in the convert dialog (at least the user will be informed).
2015-10-20 23:53:47 +02:00
#include <cairo.h>
app,libgimp*: fix includes to follow our include policy - don't include <gdk-pixbuf/gdk-pixbuf.h> in headers in app/ - instead, include it in many .c files instead of <glib-object.h>, finally acknowledging the fact that app/ depends on gdk-pixbuf almost globally - fix up includes as if libgimpbase depended in GIO, which it soon will
2013-10-15 01:58:39 +02:00
#include <gdk-pixbuf/gdk-pixbuf.h>
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
#include <gegl.h>
Initial space invasion commit in GIMP All babl formats now have a space equivalent to a color profile, determining the format's primaries and TRCs. This commit makes GIMP aware of this. libgimp: - enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA as deprecated aliases, add PERCEPTUAL values so we now have LINEAR, NON_LINEAR and PERCPTUAL for each encoding, matching the babl encoding variants RGB, R'G'B' and R~G~B~. - gimp_color_transform_can_gegl_copy() now returns TRUE if both profiles can return a babl space, increasing the amount of fast babl color conversions significantly. - TODO: no solution yet for getting libgimp drawable proxy buffers in the right format with space. plug-ins: - follow the GimpPrecision change. - TODO: everything else unchanged and partly broken or sub-optimal, like setting a new image's color profile too late. app: - add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as replacement for all "linear" booleans. - change gimp-babl functions to take babl spaces and GimpTRCType parameters and support all sorts of new perceptual ~ formats. - a lot of places changed in the early days of goat invasion didn't take advantage of gimp-babl utility functions and constructed formats manually. They all needed revisiting and many now use much simpler code calling gimp-babl API. - change gimp_babl_format_get_color_profile() to really extract a newly allocated color profile from the format, and add gimp_babl_get_builtin_color_profile() which does the same as gimp_babl_format_get_color_profile() did before. Visited all callers to decide whether they are looking for the format's actual profile, or for one of the builtin profiles, simplifying code that only needs builtin profiles. - drawables have a new get_space_api(), get_linear() is now get_trc(). - images now have a "layer space" and an API to get it, gimp_image_get_layer_format() returns formats in that space. - an image's layer space is created from the image's color profile, change gimpimage-color-profile to deal with that correctly - change many babl_format() calls to babl_format_with_space() and take the space from passed formats or drawables - add function gimp_layer_fix_format_space() which replaces the layer's buffer with one that has the image's layer format, but doesn't change pixel values - use gimp_layer_fix_format_space() to make sure layers loaded from XCF and created by plug-ins have the right space when added to the image, because it's impossible to always assign the right space upon layer creation - "assign color profile" and "discard color profile" now require use of gimp_layer_fix_format_space() too because the profile is now embedded in all formats via the space. Add gimp_image_assign_color_profile() which does all that and call it instead of a simple gimp_image_set_color_profile(), also from the PDB set-color-profile functions, which are essentially "assign" and "discard" calls. - generally, make sure a new image's color profile is set before adding layers to it, gimp_image_set_color_profile() is more than before considered know-what-you-are-doing API. - take special precaution in all places that call gimp_drawable_convert_type(), we now must pass a new_profile from all callers that convert layers within the same image (such as image_convert_type, image_convert_precision), because the layer's new space can't be determined from the image's layer format during the call. - change all "linear" properties to "trc", in all config objects like for levels and curves, in the histogram, in the widgets. This results in some GUI that now has three choices instead of two. TODO: we might want to reduce that back to two later. - keep "linear" boolean properties around as compat if needed for file pasring, but always convert the parsed parsed boolean to GimpTRCType. - TODO: the image's "enable color management" switch is currently broken, will fix that in another commit.
2018-07-21 14:23:01 +02:00
#include "libgimpbase/gimpbase.h"
Bug 751553 - Linear precision doesn't display the image correctly When converting and image with a color profileimage between linear and gamma, create a new profile using the new API in GimpColorProfile, convert the layers to that profile and tag the image with the new profile. If creating a new profile fails, convert to the right builtin profile (linear rgb or sRGB from GimpColorProfile), but that code should be considered a fallback that will be prevented from happening in the convert dialog (at least the user will be informed).
2015-10-20 23:53:47 +02:00
#include "libgimpcolor/gimpcolor.h"
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
#include "core-types.h"
Bug 751553 - Linear precision doesn't display the image correctly When converting and image with a color profileimage between linear and gamma, create a new profile using the new API in GimpColorProfile, convert the layers to that profile and tag the image with the new profile. If creating a new profile fails, convert to the right builtin profile (linear rgb or sRGB from GimpColorProfile), but that code should be considered a fallback that will be prevented from happening in the convert dialog (at least the user will be informed).
2015-10-20 23:53:47 +02:00
#include "gegl/gimp-babl.h"
app: use gimp_gegl_buffer_copy() all over the place Replace all uses of gegl_buffer_copy() in app/ with gimp_gegl_buffer_copy(), added in the previous commit.
2018-05-24 10:21:21 -04:00
#include "gegl/gimp-gegl-loops.h"
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
#include "gimpchannel.h"
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
#include "gimpdrawable.h"
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
#include "gimpdrawable-operation.h"
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
#include "gimpimage.h"
Bug 751553 - Linear precision doesn't display the image correctly When converting and image with a color profileimage between linear and gamma, create a new profile using the new API in GimpColorProfile, convert the layers to that profile and tag the image with the new profile. If creating a new profile fails, convert to the right builtin profile (linear rgb or sRGB from GimpColorProfile), but that code should be considered a fallback that will be prevented from happening in the convert dialog (at least the user will be informed).
2015-10-20 23:53:47 +02:00
#include "gimpimage-color-profile.h"
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
#include "gimpimage-convert-precision.h"
#include "gimpimage-undo.h"
#include "gimpimage-undo-push.h"
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
#include "gimpobjectqueue.h"
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
#include "gimpprogress.h"
Bug 352823 - Changing image mode discards text layer information For conversions that have no dither options (like RGB -> GRAY or u8 -> u16), always preserve text editability, for conversions that have dither options (like RGB -> INDEXED or u16 -> u8), give the user the choice whether to enable dithering.
2012-11-10 18:56:44 +01:00
#include "text/gimptextlayer.h"
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
#include "gimp-intl.h"
void
app, pdb: use GeglDitherMethod instead of simply an integer
2016-11-07 20:41:39 +01:00
gimp_image_convert_precision (GimpImage *image,
GimpPrecision precision,
GeglDitherMethod layer_dither_type,
GeglDitherMethod text_layer_dither_type,
GeglDitherMethod mask_dither_type,
GimpProgress *progress)
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
{
Issue #3495: broken conversion when changing TRC. When converting an image TRC (or a precision+TRC change), we used to convert the profile to a linear (resp. sRGB TRC) variant or use the builtin profile, which we'd set on the image. Pippin is telling me that "it used to be that linear and non-linear precision gave different results, rather than only about how things were stored". Yet this is not needed anymore. Nowadays "RGBA foo" + any profile is linear anyway, disregarding the profile's TRC. Furthermore, this way, we don't lose the original TRC in a non-linear -> linear -> non-linear roundtrip and we simplify the code, which fixes such problems as shown in #3495 as a side effect.
2024-09-11 12:42:03 +02:00
GimpColorProfile *profile;
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
GimpObjectQueue *queue;
Bug 794721 - CRITICAL converting image precision In gimp_image_convert_precision(), don't overwrite the 'progress' parameter with the object queue, since we need to call gimp_progress_end() on it at the end of the process.
2018-03-27 09:34:42 -04:00
GimpProgress *sub_progress;
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
GList *layers;
GimpDrawable *drawable;
Initial space invasion commit in GIMP All babl formats now have a space equivalent to a color profile, determining the format's primaries and TRCs. This commit makes GIMP aware of this. libgimp: - enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA as deprecated aliases, add PERCEPTUAL values so we now have LINEAR, NON_LINEAR and PERCPTUAL for each encoding, matching the babl encoding variants RGB, R'G'B' and R~G~B~. - gimp_color_transform_can_gegl_copy() now returns TRUE if both profiles can return a babl space, increasing the amount of fast babl color conversions significantly. - TODO: no solution yet for getting libgimp drawable proxy buffers in the right format with space. plug-ins: - follow the GimpPrecision change. - TODO: everything else unchanged and partly broken or sub-optimal, like setting a new image's color profile too late. app: - add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as replacement for all "linear" booleans. - change gimp-babl functions to take babl spaces and GimpTRCType parameters and support all sorts of new perceptual ~ formats. - a lot of places changed in the early days of goat invasion didn't take advantage of gimp-babl utility functions and constructed formats manually. They all needed revisiting and many now use much simpler code calling gimp-babl API. - change gimp_babl_format_get_color_profile() to really extract a newly allocated color profile from the format, and add gimp_babl_get_builtin_color_profile() which does the same as gimp_babl_format_get_color_profile() did before. Visited all callers to decide whether they are looking for the format's actual profile, or for one of the builtin profiles, simplifying code that only needs builtin profiles. - drawables have a new get_space_api(), get_linear() is now get_trc(). - images now have a "layer space" and an API to get it, gimp_image_get_layer_format() returns formats in that space. - an image's layer space is created from the image's color profile, change gimpimage-color-profile to deal with that correctly - change many babl_format() calls to babl_format_with_space() and take the space from passed formats or drawables - add function gimp_layer_fix_format_space() which replaces the layer's buffer with one that has the image's layer format, but doesn't change pixel values - use gimp_layer_fix_format_space() to make sure layers loaded from XCF and created by plug-ins have the right space when added to the image, because it's impossible to always assign the right space upon layer creation - "assign color profile" and "discard color profile" now require use of gimp_layer_fix_format_space() too because the profile is now embedded in all formats via the space. Add gimp_image_assign_color_profile() which does all that and call it instead of a simple gimp_image_set_color_profile(), also from the PDB set-color-profile functions, which are essentially "assign" and "discard" calls. - generally, make sure a new image's color profile is set before adding layers to it, gimp_image_set_color_profile() is more than before considered know-what-you-are-doing API. - take special precaution in all places that call gimp_drawable_convert_type(), we now must pass a new_profile from all callers that convert layers within the same image (such as image_convert_type, image_convert_precision), because the layer's new space can't be determined from the image's layer format during the call. - change all "linear" properties to "trc", in all config objects like for levels and curves, in the histogram, in the widgets. This results in some GUI that now has three choices instead of two. TODO: we might want to reduce that back to two later. - keep "linear" boolean properties around as compat if needed for file pasring, but always convert the parsed parsed boolean to GimpTRCType. - TODO: the image's "enable color management" switch is currently broken, will fix that in another commit.
2018-07-21 14:23:01 +02:00
const gchar *enum_desc;
gchar *undo_desc = NULL;
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
g_return_if_fail (GIMP_IS_IMAGE (image));
g_return_if_fail (precision != gimp_image_get_precision (image));
app, pdb: use gimp_babl_is_valid() in more places Use gimp_babl_is_valid(), added in the previous commit, to validate image-type/precision combinations in various functions.
2018-07-06 13:43:26 -04:00
g_return_if_fail (gimp_babl_is_valid (gimp_image_get_base_type (image),
precision));
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
g_return_if_fail (progress == NULL || GIMP_IS_PROGRESS (progress));
Initial space invasion commit in GIMP All babl formats now have a space equivalent to a color profile, determining the format's primaries and TRCs. This commit makes GIMP aware of this. libgimp: - enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA as deprecated aliases, add PERCEPTUAL values so we now have LINEAR, NON_LINEAR and PERCPTUAL for each encoding, matching the babl encoding variants RGB, R'G'B' and R~G~B~. - gimp_color_transform_can_gegl_copy() now returns TRUE if both profiles can return a babl space, increasing the amount of fast babl color conversions significantly. - TODO: no solution yet for getting libgimp drawable proxy buffers in the right format with space. plug-ins: - follow the GimpPrecision change. - TODO: everything else unchanged and partly broken or sub-optimal, like setting a new image's color profile too late. app: - add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as replacement for all "linear" booleans. - change gimp-babl functions to take babl spaces and GimpTRCType parameters and support all sorts of new perceptual ~ formats. - a lot of places changed in the early days of goat invasion didn't take advantage of gimp-babl utility functions and constructed formats manually. They all needed revisiting and many now use much simpler code calling gimp-babl API. - change gimp_babl_format_get_color_profile() to really extract a newly allocated color profile from the format, and add gimp_babl_get_builtin_color_profile() which does the same as gimp_babl_format_get_color_profile() did before. Visited all callers to decide whether they are looking for the format's actual profile, or for one of the builtin profiles, simplifying code that only needs builtin profiles. - drawables have a new get_space_api(), get_linear() is now get_trc(). - images now have a "layer space" and an API to get it, gimp_image_get_layer_format() returns formats in that space. - an image's layer space is created from the image's color profile, change gimpimage-color-profile to deal with that correctly - change many babl_format() calls to babl_format_with_space() and take the space from passed formats or drawables - add function gimp_layer_fix_format_space() which replaces the layer's buffer with one that has the image's layer format, but doesn't change pixel values - use gimp_layer_fix_format_space() to make sure layers loaded from XCF and created by plug-ins have the right space when added to the image, because it's impossible to always assign the right space upon layer creation - "assign color profile" and "discard color profile" now require use of gimp_layer_fix_format_space() too because the profile is now embedded in all formats via the space. Add gimp_image_assign_color_profile() which does all that and call it instead of a simple gimp_image_set_color_profile(), also from the PDB set-color-profile functions, which are essentially "assign" and "discard" calls. - generally, make sure a new image's color profile is set before adding layers to it, gimp_image_set_color_profile() is more than before considered know-what-you-are-doing API. - take special precaution in all places that call gimp_drawable_convert_type(), we now must pass a new_profile from all callers that convert layers within the same image (such as image_convert_type, image_convert_precision), because the layer's new space can't be determined from the image's layer format during the call. - change all "linear" properties to "trc", in all config objects like for levels and curves, in the histogram, in the widgets. This results in some GUI that now has three choices instead of two. TODO: we might want to reduce that back to two later. - keep "linear" boolean properties around as compat if needed for file pasring, but always convert the parsed parsed boolean to GimpTRCType. - TODO: the image's "enable color management" switch is currently broken, will fix that in another commit.
2018-07-21 14:23:01 +02:00
gimp_enum_get_value (GIMP_TYPE_PRECISION, precision,
NULL, NULL, &enum_desc, NULL);
undo_desc = g_strdup_printf (C_("undo-type", "Convert Image to %s"),
enum_desc);
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
if (progress)
app: some GimpProgress cleanup - change start() and set_text() to use "format" and "..." instead of "message", allowing to format progress messages in place - s/cancelable/cancellable/ - move "cancellable" to be the second argument of start()
2014-07-12 23:45:20 +02:00
gimp_progress_start (progress, FALSE, "%s", undo_desc);
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
Bug 794721 - CRITICAL converting image precision In gimp_image_convert_precision(), don't overwrite the 'progress' parameter with the object queue, since we need to call gimp_progress_end() on it at the end of the process.
2018-03-27 09:34:42 -04:00
queue = gimp_object_queue_new (progress);
sub_progress = GIMP_PROGRESS (queue);
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
layers = gimp_image_get_layer_list (image);
gimp_object_queue_push_list (queue, layers);
g_list_free (layers);
gimp_object_queue_push (queue, gimp_image_get_mask (image));
gimp_object_queue_push_container (queue, gimp_image_get_channels (image));
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
g_object_freeze_notify (G_OBJECT (image));
gimp_image_undo_group_start (image, GIMP_UNDO_GROUP_IMAGE_CONVERT,
undo_desc);
Initial space invasion commit in GIMP All babl formats now have a space equivalent to a color profile, determining the format's primaries and TRCs. This commit makes GIMP aware of this. libgimp: - enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA as deprecated aliases, add PERCEPTUAL values so we now have LINEAR, NON_LINEAR and PERCPTUAL for each encoding, matching the babl encoding variants RGB, R'G'B' and R~G~B~. - gimp_color_transform_can_gegl_copy() now returns TRUE if both profiles can return a babl space, increasing the amount of fast babl color conversions significantly. - TODO: no solution yet for getting libgimp drawable proxy buffers in the right format with space. plug-ins: - follow the GimpPrecision change. - TODO: everything else unchanged and partly broken or sub-optimal, like setting a new image's color profile too late. app: - add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as replacement for all "linear" booleans. - change gimp-babl functions to take babl spaces and GimpTRCType parameters and support all sorts of new perceptual ~ formats. - a lot of places changed in the early days of goat invasion didn't take advantage of gimp-babl utility functions and constructed formats manually. They all needed revisiting and many now use much simpler code calling gimp-babl API. - change gimp_babl_format_get_color_profile() to really extract a newly allocated color profile from the format, and add gimp_babl_get_builtin_color_profile() which does the same as gimp_babl_format_get_color_profile() did before. Visited all callers to decide whether they are looking for the format's actual profile, or for one of the builtin profiles, simplifying code that only needs builtin profiles. - drawables have a new get_space_api(), get_linear() is now get_trc(). - images now have a "layer space" and an API to get it, gimp_image_get_layer_format() returns formats in that space. - an image's layer space is created from the image's color profile, change gimpimage-color-profile to deal with that correctly - change many babl_format() calls to babl_format_with_space() and take the space from passed formats or drawables - add function gimp_layer_fix_format_space() which replaces the layer's buffer with one that has the image's layer format, but doesn't change pixel values - use gimp_layer_fix_format_space() to make sure layers loaded from XCF and created by plug-ins have the right space when added to the image, because it's impossible to always assign the right space upon layer creation - "assign color profile" and "discard color profile" now require use of gimp_layer_fix_format_space() too because the profile is now embedded in all formats via the space. Add gimp_image_assign_color_profile() which does all that and call it instead of a simple gimp_image_set_color_profile(), also from the PDB set-color-profile functions, which are essentially "assign" and "discard" calls. - generally, make sure a new image's color profile is set before adding layers to it, gimp_image_set_color_profile() is more than before considered know-what-you-are-doing API. - take special precaution in all places that call gimp_drawable_convert_type(), we now must pass a new_profile from all callers that convert layers within the same image (such as image_convert_type, image_convert_precision), because the layer's new space can't be determined from the image's layer format during the call. - change all "linear" properties to "trc", in all config objects like for levels and curves, in the histogram, in the widgets. This results in some GUI that now has three choices instead of two. TODO: we might want to reduce that back to two later. - keep "linear" boolean properties around as compat if needed for file pasring, but always convert the parsed parsed boolean to GimpTRCType. - TODO: the image's "enable color management" switch is currently broken, will fix that in another commit.
2018-07-21 14:23:01 +02:00
g_free (undo_desc);
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
app: fix comment in gimp_image_convert_precision()
2012-05-05 21:41:20 +02:00
/* Push the image precision to the stack */
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
gimp_image_undo_push_image_precision (image, NULL);
Issue #3495: broken conversion when changing TRC. When converting an image TRC (or a precision+TRC change), we used to convert the profile to a linear (resp. sRGB TRC) variant or use the builtin profile, which we'd set on the image. Pippin is telling me that "it used to be that linear and non-linear precision gave different results, rather than only about how things were stored". Yet this is not needed anymore. Nowadays "RGBA foo" + any profile is linear anyway, disregarding the profile's TRC. Furthermore, this way, we don't lose the original TRC in a non-linear -> linear -> non-linear roundtrip and we simplify the code, which fixes such problems as shown in #3495 as a side effect.
2024-09-11 12:42:03 +02:00
/* Use the actual image's profile, and in particular don't be clever
* by using a builtin profile. I.e. don't use gimp_color_managed_get_color_profile().
* We don't want a profile change, and the format is enough to take
* care of any TRC override if needed.
*/
profile = gimp_image_get_color_profile (image);
Bug 751553 - Linear precision doesn't display the image correctly When converting and image with a color profileimage between linear and gamma, create a new profile using the new API in GimpColorProfile, convert the layers to that profile and tag the image with the new profile. If creating a new profile fails, convert to the right builtin profile (linear rgb or sRGB from GimpColorProfile), but that code should be considered a fallback that will be prevented from happening in the convert dialog (at least the user will be informed).
2015-10-20 23:53:47 +02:00
app: fix a crash when converting to higher precision. gimp_display_shell_render() writes to a GeglBuffer backed by allocated memory (shell->profile_data). Unfortunately while converting prevision in gimp_image_convert_precision(), we change the "precision" property (hence the source format) first, hence end up trying to write data in a too small buffer. This crash was hard to find as it was not showing up on my machine (though it did produce rendering artifacts!), unless I built both GIMP and babl with `b_sanitize=address`. Note that an alternate fix was to make sure that the profile_data buffer is big enough (by calling gimp_display_shell_profile_update() before rendering), but anyway the image is in an inconsistent state while conversion is in progress: whereas the `src_format` is the new one, the `src_profile` is still the old one (and cannot be changed before we finish converting). Moreover the render happen regularly on progress signals, once after each converted drawable. So each of these rendering step happens in an inconsistent state, with the wrong profile set, some of the drawables converted and others not yet. We could still render properly if each drawable's buffer used space-aware format (thus allowing different drawables to use different profiles/spaces), but it feels over-engineering the problem. It might be much better to ignore rendering steps while converting the image precision. Moreover it would obviously make a faster conversion. See discussions in #9136 for this crash, which didn't have dedicated report AFAIK. (cherry picked from commit de25be92104e6883cb35ea7bf0ea12408c8ca722) Note: on the `master` branch, even with sanitized code, I don't get the crash. Yet this change seems relevant enough that I'm adding it.
2023-02-19 13:54:03 +01:00
gimp_image_set_converting (image, TRUE);
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
/* Set the new precision */
g_object_set (image, "precision", precision, NULL);
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
while ((drawable = gimp_object_queue_pop (queue)))
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
{
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
if (drawable == GIMP_DRAWABLE (gimp_image_get_mask (image)))
{
GeglBuffer *buffer;
Bug 352823 - Changing image mode discards text layer information For conversions that have no dither options (like RGB -> GRAY or u8 -> u16), always preserve text editability, for conversions that have dither options (like RGB -> INDEXED or u16 -> u8), give the user the choice whether to enable dithering.
2012-11-10 18:56:44 +01:00
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
gimp_image_undo_push_mask_precision (image, NULL,
GIMP_CHANNEL (drawable));
buffer = gegl_buffer_new (GEGL_RECTANGLE (0, 0,
gimp_image_get_width (image),
gimp_image_get_height (image)),
gimp_image_get_mask_format (image));
app: use gimp_gegl_buffer_copy() all over the place Replace all uses of gegl_buffer_copy() in app/ with gimp_gegl_buffer_copy(), added in the previous commit.
2018-05-24 10:21:21 -04:00
gimp_gegl_buffer_copy (gimp_drawable_get_buffer (drawable), NULL,
GEGL_ABYSS_NONE,
buffer, NULL);
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
gimp_drawable_set_buffer (drawable, FALSE, NULL, buffer);
g_object_unref (buffer);
app: in gimp_image_convert_precision(), report progress for selection mask
2018-03-27 09:36:28 -04:00
gimp_progress_set_value (sub_progress, 1.0);
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
}
Bug 352823 - Changing image mode discards text layer information For conversions that have no dither options (like RGB -> GRAY or u8 -> u16), always preserve text editability, for conversions that have dither options (like RGB -> INDEXED or u16 -> u8), give the user the choice whether to enable dithering.
2012-11-10 18:56:44 +01:00
else
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
{
Issue #1954 - GIMP-2.99 color changes when converting between... ...linear and perceptual precision Under certain circumstances (e.g. the image has no color profile), GimpLayer's implementation of GimpDrawable::convert_type() didn't have enough information to do the right color space conversion. Intead of messing with stuff like "set profile in between doing a and b", simply add a "src_profile" parameter to GimpDrawable::convert_type() so the complete color space conversion information is available without relying on obscure states that could change in the future. Make sure all callers pass the right src_profile, particularly in gimp_image_convert_precision(), which also needed fixing.
2018-08-05 22:19:17 +02:00
GeglDitherMethod dither_type;
Bug 751553 - Linear precision doesn't display the image correctly When converting and image with a color profileimage between linear and gamma, create a new profile using the new API in GimpColorProfile, convert the layers to that profile and tag the image with the new profile. If creating a new profile fails, convert to the right builtin profile (linear rgb or sRGB from GimpColorProfile), but that code should be considered a fallback that will be prevented from happening in the convert dialog (at least the user will be informed).
2015-10-20 23:53:47 +02:00
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
if (gimp_item_is_text_layer (GIMP_ITEM (drawable)))
dither_type = text_layer_dither_type;
else
dither_type = layer_dither_type;
gimp_drawable_convert_type (drawable, image,
gimp_drawable_get_base_type (drawable),
precision,
gimp_drawable_has_alpha (drawable),
Issue #3495: broken conversion when changing TRC. When converting an image TRC (or a precision+TRC change), we used to convert the profile to a linear (resp. sRGB TRC) variant or use the builtin profile, which we'd set on the image. Pippin is telling me that "it used to be that linear and non-linear precision gave different results, rather than only about how things were stored". Yet this is not needed anymore. Nowadays "RGBA foo" + any profile is linear anyway, disregarding the profile's TRC. Furthermore, this way, we don't lose the original TRC in a non-linear -> linear -> non-linear roundtrip and we simplify the code, which fixes such problems as shown in #3495 as a side effect.
2024-09-11 12:42:03 +02:00
profile, profile,
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
dither_type,
mask_dither_type,
Bug 794721 - CRITICAL converting image precision In gimp_image_convert_precision(), don't overwrite the 'progress' parameter with the object queue, since we need to call gimp_progress_end() on it at the end of the process.
2018-03-27 09:34:42 -04:00
TRUE, sub_progress);
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
}
}
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
Issue #3495: broken conversion when changing TRC. When converting an image TRC (or a precision+TRC change), we used to convert the profile to a linear (resp. sRGB TRC) variant or use the builtin profile, which we'd set on the image. Pippin is telling me that "it used to be that linear and non-linear precision gave different results, rather than only about how things were stored". Yet this is not needed anymore. Nowadays "RGBA foo" + any profile is linear anyway, disregarding the profile's TRC. Furthermore, this way, we don't lose the original TRC in a non-linear -> linear -> non-linear roundtrip and we simplify the code, which fixes such problems as shown in #3495 as a side effect.
2024-09-11 12:42:03 +02:00
gimp_color_managed_profile_changed (GIMP_COLOR_MANAGED (image));
Bug 751553 - Linear precision doesn't display the image correctly When converting and image with a color profileimage between linear and gamma, create a new profile using the new API in GimpColorProfile, convert the layers to that profile and tag the image with the new profile. If creating a new profile fails, convert to the right builtin profile (linear rgb or sRGB from GimpColorProfile), but that code should be considered a fallback that will be prevented from happening in the convert dialog (at least the user will be informed).
2015-10-20 23:53:47 +02:00
app: fix a crash when converting to higher precision. gimp_display_shell_render() writes to a GeglBuffer backed by allocated memory (shell->profile_data). Unfortunately while converting prevision in gimp_image_convert_precision(), we change the "precision" property (hence the source format) first, hence end up trying to write data in a too small buffer. This crash was hard to find as it was not showing up on my machine (though it did produce rendering artifacts!), unless I built both GIMP and babl with `b_sanitize=address`. Note that an alternate fix was to make sure that the profile_data buffer is big enough (by calling gimp_display_shell_profile_update() before rendering), but anyway the image is in an inconsistent state while conversion is in progress: whereas the `src_format` is the new one, the `src_profile` is still the old one (and cannot be changed before we finish converting). Moreover the render happen regularly on progress signals, once after each converted drawable. So each of these rendering step happens in an inconsistent state, with the wrong profile set, some of the drawables converted and others not yet. We could still render properly if each drawable's buffer used space-aware format (thus allowing different drawables to use different profiles/spaces), but it feels over-engineering the problem. It might be much better to ignore rendering steps while converting the image precision. Moreover it would obviously make a faster conversion. See discussions in #9136 for this crash, which didn't have dedicated report AFAIK. (cherry picked from commit de25be92104e6883cb35ea7bf0ea12408c8ca722) Note: on the `master` branch, even with sanitized code, I don't get the crash. Yet this change seems relevant enough that I'm adding it.
2023-02-19 13:54:03 +01:00
gimp_image_set_converting (image, FALSE);
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
gimp_image_undo_group_end (image);
gimp_image_precision_changed (image);
g_object_thaw_notify (G_OBJECT (image));
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
g_object_unref (queue);
app: add progress reporting to gimp_drawable_convert_type() so it doesn't sit there appearing to do nothing while converting an image with profile to gamma/linear.
2015-10-21 22:22:30 +02:00
app: move gimp_image_convert_precision() to its own file gimpimage-convert.c is big enough already
2012-04-29 16:22:20 +02:00
if (progress)
gimp_progress_end (progress);
}
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
void
gimp_image_convert_dither_u8 (GimpImage *image,
GimpProgress *progress)
{
GeglNode *dither;
g_return_if_fail (GIMP_IS_IMAGE (image));
g_return_if_fail (progress == NULL || GIMP_IS_PROGRESS (progress));
dither = gegl_node_new_child (NULL,
"operation", "gegl:noise-rgb",
Bug 794753 - do not dither image mask and channels for imported images By the same logic of commit 44f293bcdb241f49b22a8df00d7f90f350f24005, we shouldn't dither the alpha channel either.
2018-03-29 03:03:51 -04:00
"red", 1.0 / 256.0,
"green", 1.0 / 256.0,
"blue", 1.0 / 256.0,
"linear", FALSE,
"gaussian", FALSE,
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
NULL);
if (dither)
{
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
GimpObjectQueue *queue;
app: call gimp_progress_end() at gimp_image_convert_dither_u8() exit
2018-03-29 03:01:23 -04:00
GimpProgress *sub_progress;
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
GList *layers;
GList *list;
GimpDrawable *drawable;
if (progress)
gimp_progress_start (progress, FALSE, "%s", _("Dithering"));
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
app: call gimp_progress_end() at gimp_image_convert_dither_u8() exit
2018-03-29 03:01:23 -04:00
queue = gimp_object_queue_new (progress);
sub_progress = GIMP_PROGRESS (queue);
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
layers = gimp_image_get_layer_list (image);
for (list = layers; list; list = g_list_next (list))
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
{
if (! gimp_viewable_get_children (list->data) &&
! gimp_item_is_text_layer (list->data))
{
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
gimp_object_queue_push (queue, list->data);
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
}
}
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
g_list_free (layers);
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
while ((drawable = gimp_object_queue_pop (queue)))
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
{
app: call gimp_progress_end() at gimp_image_convert_dither_u8() exit
2018-03-29 03:01:23 -04:00
gimp_drawable_apply_operation (drawable, sub_progress,
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
_("Dithering"),
dither);
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
}
app: use GimpObjectQueue in lots of places Use GimpObjectQueue, added in the previous commit, in various instances where we perform an action on a set of objects. This improves progress reporting, by using a single progress for the entire operation, rather than reporting the progress of each object individually, and by taking the relative cost of each object into account, instead of assuming a uniform cost for all objects. In particular, this affects the various whole-image operations (i.e., transformations and color conversions), operations on linked items, and operations on layer groups. This also affects layers with masks, whose progress is now reported together instead of individually. Additionally, this commit fixes erroneous group-layer mask cropping during undo when resizing the image, by properly calling {start,end}_move() on all the resized layers before starting the operation, and when scaling the image, by only scaling top-level layers, and letting group layers scale their children themselves.
2018-03-25 10:18:46 -04:00
g_object_unref (queue);
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
app: call gimp_progress_end() at gimp_image_convert_dither_u8() exit
2018-03-29 03:01:23 -04:00
if (progress)
gimp_progress_end (progress);
Bug 734657 - Import as 32-bit floating-point linear by default Optionally convert all imported (not XCFs) images to 32 bit linear floating point, and optionally add a little noise in order to distribute the colors minimally. The new options are on a new "Image Import & Export" prefs page that needs a new icon. Original dithering patch by pippin.
2017-01-22 22:03:55 +01:00
g_object_unref (dither);
}
}
Copy Permalink