Make sure a channel -> selection -> channel roundtrip never does any
gamma conversion.
In gimp_channel_duplicate(), make sure a created channel has the
right format, and the right data. Fixes selection -> channel.
When switching off quick mask, call gimp_item_to_selection() instead
if gimp_selection_load(), the latter was implementing a shortcut which
is now wrong.
Remove gimp_selection_load() which is now unused.
Unrelated: also remove gimp_selection_save(), it was an obvious
3-liner used only twice.
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
Add a GimpFillType argument to GimpItem::resize() and fill type
widgets to the canvas and layer resize dialogs. Fill the new parts of
the drawable according to fill type in gimp_drawable_resize(). Make
sure places that need the old behavior get GIMP_FILL_TRANSPARENT
passed by hardcoding it in the GimpItem::resize() implemetations of
channel, mask, selection etc.
making its external API "complete". Remove the redundant
"new_base_type" and "new_precision" from the internal (vfunc) API (the
Babl format has the same information).
They are unreliable because every type checking cast discards them,
they are useless anyway, visual clutter, added inconsistently, and
generally suck. Wanted to do this a long time ago, it was a bad idea
in the first place.
isntead of the feather parameter, and pass it to
gimp_gegl_apply_border().
Make the necessary changes to the rest of the code to maintain the
current behavior.
Mass parameter alignment changes to gimpchannel.h. Sigh #2...
This doesn make any difference because a NULL profile would do the
same, but it's safer to pass the actual profile instead of relying on
the magic meaning of NULL in the call to
gimp_layer_new_from_gegl_buffer().
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.
After discussion in IRC some weeks ago give the Selection-Flood items
the more meaningful name Selection-Remove holes.
modified: app/actions/select-actions.c
modified: app/core/gimpselection.c
For selections, it's different from gimp_edit_fill() because it
ignores the selection while filling, just as stroking does. Currently
unused, stay tuned...
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.
and pass them where we know the buffer could be from another image.
Pass "NULL, 0" if we know it's the same image.
Add gimp_layer_new_convert_profile() which takes the newly created
layer and the ICC data/length; call it from both
gimp_layer_new_from_gegl_buffer() and gimp_layer_new_from_pixbuf().
gimp_layer_new_convert_profile() is empty, this is just
infrastructure.
- 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
but only to the virtual function, not the public API. Implement it in
GimpSelection and GimpLayerMask, and pass the correct mask format down
to the parent class which does the actual conversion.
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.
and use it instead of gimp_babl_format() in some places where indexed
formats can occur. Also fix some places using gimp_babl_format() to
special case indexed formats correctly.
GIMP was doing evil hacks lying to GEGL about it's pixels being in a linear
color space when they are not. This causes incorrect rendering, makes gaussian
blur misbehave etc.
The legacy projection modes should be implemented using the same 2.2 gamma
formats that are correct to specify for sRGB data. (for proper color
management in higher bitdepths; icc backend babl formats should be used.)
For the old image modes correct babl formats are:
R'G'B'A u8 - 8 bit RGB with 2.2 gamma (sRGB) with linear alpha component
R'G'B' u8 - 8 bit RGB with 2.2 gamma (sRGB)
Y'A u8 - 8 bit Grayscale with 2.2 gamma with linear alpha component
Y' u8 - 8 bit Grayscale with 2.2 gamma
Y u8 - 8 bit linear data, used for masks/channels
A u8 - 8 bit linear alpha
-----------------------------------------------
RGBA float - 32bit floating point linear light RGB
RaGaBaA float - 32bit floating point linear light RGB, premultiplied alpha
to be used for processing that needs to scale by the alpha,
(blurs, resampling etc)
R'G'B'A float - 32bit floating point sRGB with gamma, to be used where
the result depends on being closer to perceptual when
processing, can be used a cheaper alternative to CIE Lab
based modes.
-----------------------------------------------
The legacy layer modes should use the formats with gamma 2.2 only for loading
and rendering legacy XCF files correctly, in the brave new world compositing
should most likely be done in linear light with "RGBA float" and even better
"RaGaBaA float" like GEGL does for porter duff and other compositing modes.
The ability to chose the legacy layer modes should probably be hidden from the
user unless an old .xcf has been opened.
