Not only the logic was broken, a local variable was also shadowing the
"dest_profile" variable and preventing the broken logic to be applied
at all. Double fail.
instead of just a boolean "convert_profile". This takes the logic to
figure the right target profile out of gimp_layer_convert_type(), it
can't possibly know everything about how to convert anyway, and having
the logic in the callers conveniently splits it up and distributes its
parts to the places they belong.
This commit should cause no behavor change and is just preparation for
fixing bug 765176.
Rename profile constructors to say "d65_gray" instead of just "gray",
"srgb_trc" instead of "srgb_gamma", and drop the "srgb" from
"srgb_linear" because we now say "d65". This should be a naming scheme
that doesn't conflict with whatever future functions we might add.
Support creating linear/sRGB-gamma variants of gray profiles and
rename gimp_color_profile_new_linear_rgb_from_color_profile() to
gimp_color_profile_new_linear_gamma_from_color_profile() because it's
not RGB-specific any longer.
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).
also add "GType old_type" to GimpItem::convert() so implementations
can do things depending on the type of the original item.
In gimp_layer_convert(), if the original item is also a layer, and
color management is not off (with a FIXME because this is the wrong
check), pass convert_profile = TRUE to gimp_drawable_convert_type().
There is no color profile conversion anywhere behind this, this is
just an API change commit.
- 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()
- 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
- Add new enum GimpComponentType which contains u8, u16, u32 etc.
- Change GimpPrecision to be u8-linear, u8-gamma, u16-linear etc.
- Add all the needed formats to gimp-babl.c
- Bump the XCF version to 5 and make sure version 4 with the old
GimpPrecision enum values is loaded correctly
This change blows up the precision enums in "New Image" and
Image->Precision so we can test all this stuff. It is undecided what
format will be user-visible options in 2.10.
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.
Add "layer_dither_type" and "mask_dither_type" to
GimpDrawable::convert_type(), pass around the dither type from the
dialog, and implement dithering using gegl:color-reduction.
==7785== 96 bytes in 4 blocks are definitely lost in loss record 16,947 of 20,720
==7785== at 0x4A0884D: malloc (/builddir/build/BUILD/valgrind-3.7.0/coregrind/m_replacemalloc/vg_replace_malloc.c:263)
==7785== by 0x87F52DE: g_malloc (glib/glib/gmem.c:159)
==7785== by 0x8809741: g_slice_alloc (glib/glib/gslice.c:1003)
==7785== by 0x87EBF0D: g_list_prepend (glib/glib/glist.c:275)
==7785== by 0x6FA596: gimp_item_stack_get_item_list (gimp/app/core/gimpitemstack.c:175)
==7785== by 0x6D97B4: gimp_image_convert_precision (gimp/app/core/gimpimage-convert-precision.c:55)
==7785== by 0x49B62E: image_convert_precision_cmd_callback (gimp/app/actions/image-commands.c:236)
And along with it a lot of stuff like the drawable preview cache, the
gegl tile manager backend, temporary gimp_gegl_buffer_foo() stuff, and
the remaining bits of performance.
The projection is in an evil semi-ported state which makes it work
ok-ish for stuff like layer moving, but absolutely unbearable for
painting, there is also an off-by-one rendering glitch at some zoom
levels.
