In the Curves tool, when the image precision is greater than 8-bpc,
use a 0.00-100.00 range for the point-coordinate spin-buttons,
instead of a 0-255 range.
Allow setting the type of GimpCurve control-points to either SMOOTH
or CORNER. Smooth points produce a smooth curve, while corner
points produce a sharp curve (previously, all points were smooth).
In GimpCureView, display corner points using a diamond shape,
instead of a circle.
In the Curves tool, allow changing the curve's point types.
In GimpCurve, replace the use of a fixed-length control-point array
with a dynamically-sized array. Adapt GimpCurve's interface, and
the rest of the code.
In addition to simplifying the code, this fixes a bug where the
curve object could be broken by moving the mouse too fast (yep...),
and allows more accurate point placement, both in the GUI editor,
and through canvas interaction in the Curves tool (see issue #814).
In GimpCurveView, when holding down Ctrl while adding/dragging a
point, snap the y-coordinate to the original curve (at the start of
the drag). This is particularly useful for adding points along the
curve, without changing their y-coordinate.
Likewise, have the coordinate indicator show the snapped
coordinate.
In GimpCurveView, when dragging an existing curve point, don't
immediately move the point to the cursor position uppon button
press, but rather move it relative to its current position as the
cursor moves. This allows selecting a point without moving it, and
adjusting its position more easily.
Additionally, when the cursor hovers above a point, or when
dargging a point, have the coordinate indicator show the point's
position, rather than the cursor's.
Add an "Incremental" option to the Dodge/Burn tool, which,
similarly to the Paintbrush, Pencil, and Eraser tools, applies the
effect incrementally as the pointer moves.
... linear itself AND if we export the profile.
In most cases we want to save 8-bit image formats (here JPEG) as
non-linear, even though the work image may have been linear itself (yet
with higher bit depth). The reasons are shadow posterization on low bit
depth, and the fact that JPEG compression was designed for perceptually
uniform RGB and introduces shadow artifacts with linear RGB (see #1070,
message by Elle Stone). The only exception is when the creator was
working explicitly on 8-bit linear (not higher bit depth) AND if we
export the profile (otherwise most loaders around assume sRGB). In such
a case, let's consider the creator knows what one is doing and keep the
exported image linear.
Similar logics is already used in PNG exporter (though a bit of a
variant since PNG supports 16-bit so it is instead: 8-bit linear without
profile is promoted to 16-bit non-linear, and kept 8-bit linear with
profile).
... produces incorrect result.
Similar to previous fixes to JPEG and PNG exporters. Here WebP always
export 8-bit per channel colors, so let's always keep it non-linear.
Simply when the original data was linear, if we save the profile,
convert it to sRGB before exporting.
File extension (.gex) may still change if anything better is proposed.
This format is currently just a compressed archive containing the
extension data (plug-in, brushes or whatever) and the metadata file.
For now, opening such file will simply install it as a new extension,
keeping all file permissions and structure. Of course in the future, it
will have to trigger a confirmation dialog.
Currently the compression used is zip, which is just a first draft. This
is not a decisive choice as well. We could use some tarball compressed
in whatever other compression algorithm. I use libarchive as a new
dependency to support unarchiving as it seems to be a common library
(and since it is already used by AppStream-glib anyway, this doesn't add
any actual dependency, just make it direct).
This is useful to be able to support file formats other than image
formats. In particular I will use this in the next commit to support a
"GIMP extension" format. When GIMP will open such file, it will
install an extension (not open an image on canvas).
This is an internal flag only, i.e. only usable from core GIMP. File
formats which a plug-in can register are still only image file formats.
... linear XCF.
When choosing a specific pixel format (other than "Automatic"), we
always export as non-linear. Therefore if we were going to save a linear
profile, make sure we also convert it to sRGB too.
... produces jpeg in linear color space.
The problem was that we were anyway always exporting to non-linear while
attaching a linear profile. A first approach would have been to export
in linear instead when the work image is linear, as proposed by mitch in
a first version of the patch. Yet as Elle Stone notes, it is not a great
idea to export 8-bit images as linear.
Instead let's continue to always export as non-linear, as we were
already doing. Yet when we also save a profile, and this one was
originally linear, let's convert it to sRGB TRC before exporting.
Only seek back to after the end of the actual brush if a following
pattern was *not* found. Got this logic wrong in the original port of
the plug-in code.
Add a note asking bug reporters to test with the latest stable version
of GIMP or with dev code (not with old stable versions).
Also add some labels on bug reports and feature requests.
In GimpRectangleSelectTool, update the selection upon changes to
the "antialias", "feather", "feather-radius", "round-corners", and
"corner-radius" options, so that they take effect immediately,
without having to change the selection bounds.
Anyway Python deps does not work yet on the master build. That's
unneeded to build nightlies with Python support. Let's drop it for now
and add it back later when we will make it work.
