heif_chroma_interleaved_24|32bit are deprecated values replaced by
heif_chroma_interleaved_RGB(A).
Also we allocated a HEIF context twice (i.e. leaking it).
Finally it's better to initialize heif_image and heif_encoder variables
to NULL because these may not be set if creation functions fail (and
it's better to fail with NULL than with garbled unset contents).
- Add the quality slider in a frame under the "lossless" checkbox,
making the relationship more obvious.
- Make the whole frame contents insensitive when "lossless" is checked
and not just the slider. Once again, it makes the relationship more
obvious.
- Add a mnemonic to the "Lossless" checkbox and "Quality" slider.
This new capacity was created just 3 commits ago (9933f46f85).
The point was that the real fix is to remove the implication
HANDLE_LAYERS => HANDLE_ALPHA, but this breaks public API behavior,
which is why I didn't go with it.
Still it just felt wrong to add a NEEP_OPAQUE capability when it should
be the same thing as not setting HANDLE_ALPHA. After discussion on IRC,
we decided that this implication was basically a bug, and since in all
core plug-ins, when HANDLE_LAYERS was set, we were also setting
HANDLE_ALPHA, no core plug-in code even has to be changed. As for
third-party plug-ins, let's assume that none has been relying on this
wrong assumption.
G3/G4 compression does not support transparency, yet in multi-layer
export, gimp_export_image() capability GIMP_EXPORT_CAN_HANDLE_LAYERS
implied GIMP_EXPORT_CAN_HANDLE_ALPHA. I guess multi-layer TIFF is more
for multi-page (at least with G3/G4 which is apparently a fax format, so
it makes sense) than actual multi-layer.
So I use the new GIMP_EXPORT_NEEDS_OPAQUE_LAYERS capability from
previous commit for this particular use case of export layers + G3/G4
compression.
Also it is better to run gimp_export_image() *after* the option dialog,
as we do for other formats, with variable capabilities depending on
which options was chosen, instead of running it before then after
merging layers when user chose not to export layers. This is duplicating
the purpose of gimp_export_image().
Found in my stashes, I have no idea why I even bothered but it just
needed a minor fix to work, so here we go. Stupid port that always
uses 8 bit and kills higher bit depths.
Use gimp_image_metadata_load_finish() and pass the right flags
depending on whether comment and profile were loaded. Also, set the
profile before creating the layer so its space is correct
automatically.
Use the drawable's space for the load/save formats to avoid unwanted
color conversions. Also cleaned up the loading code a bit, it was
doing weird duplicated stuff for the preview and !preview cases.
...always AdobeRGB!
Change all file plug-ins to never call gimp_image_metadata_load_finish()
with the GIMP_METADATA_LOAD_COLORSPACE when they loaded a color profile.
This keeps gimp_image_metadata_load_finish() from assigning a profile
from DCT even if the loaded profile was GIMP's built-in sRGB.
Complete commit ac8ad13f0a.
Channels are Y' on 8-bit non-linear images. So to avoid data conversion,
this is the only case where we want to consider TIFF channels to be Y'
as well.
In GIMP, our channels (the ones from Channels dock) are always linear,
and don't follow the image/profile TRC. When a TIFF image has extra
channels (no semantic attached), we probably want to load the channel
as-is, without converting the values. So let's assume that TIFF extra
samples with "Unspecified data" in it are linear data. This way, their
values goes copied straight into a channel.
Instead of treating any unspecified TIFF channel as non-premultiplied
alpha, let's now ask the user (in non-interactive case, we continue
defaulting to non-premultiplied channel and outputing a message). The 3
choices are: premultiplied, non-premultiplied (which is the default so
you can just hit Enter and get same result as previously) and channel.
It's still not perfect as it still assumes that an alpha channel will
necessarily be the first extra channel (though the spec does not mandate
such assumption). Let's say for now that it is enough. Using extra
channels for the alpha channel only is most likely the most common usage
(actually the spec only has specific types for such usage).
...and pngs
Fix PNG import and export:
When importing, set the color profile on the image *before* creating
the layer, so its buffer has the right format with space.
When exporting, create the saving babl format with the layer's space
so no color conversion happens when reading the layer's pixels.
Note that I am using twice TIFFErrorHandler type. This is because
TIFFWarningHandler does not exist, despite what the docs says and
upstream code actually uses twice the same handler type.
...and pngs
Fix yesterday's fix and pippin's fix to not move lines around that
should be together (never move around code between testing and
pushing)...
Initialize channel[0].buffer before using it, as a response to the following
critical warning reported in issue #3264 about it being NULL:
(file-tiff:1074): GEGL-CRITICAL **: 17:10:57.175: gegl_buffer_get_format: assertion 'buffer' failed
...and pngs
Create formats with the drawable's space so no conversions happen when
reading/writing the drawable's buffer. Original patches from Massimo.
Our TIFF loading code was not taking into account the case when extra
channels were stored in the TIFF file while ExtraSamples field is not
set. Yet as a side effect of a later channel count, we were setting
`alpha` to TRUE while `save_transp_pixels` was left uninitialized (hence
undefined behavior).
For now let's make sure we have no undefined behavior. When the
ExtraSamples field is missing and at least one extra channel is stored,
we will consider the first extra channel as non-premultiplied alpha
(this is also what we were doing when ExtraSamples was set to
"Unspecified data" and apparently according to Massimo, it would be a
common behavior in other software).
Note that it is an improvement from previous code (no undefined
behaviour anymore, instead we handle explicitly the TIFF error). Yet
this is not perfect yet. Ideally we should pop-up a dialog asking what
to do with this extra channel: either open as a channel (no alpha), or
as premultiplied or non-premultiplied alpha.
While we tend to default to sRGB for 8-bit max formats (such as JPEG or
WebP) when no explicitly-assigned profile was set, there is no need to
do so for PNG too. Indeed since we have the ability to export 16-bit
PNG, let's consider this is ok to export 16-bit linear data when writing
GIMP's default linear profile.
Moreover let's follow the profile's (fallback to storage's) TRC also
when exporting to a specific precision (as chosen manually in the
dialog), not only when sticking to "Automatic", unless we are downsizing
a high bit depth work image to 8-bit without a manually assigned profile
(the only case we forcefully export as sRGB data, hence convert the
profile if linear storage).
... in JPEG export.
Same as the WebP export, which is quite similar (8-bit max format), when
no profile was explicitly set, we want to convert any data from storage
format to non-linear (unlike when exporting high bit depth formats, such
as TIFF).
We only make an exception for 8-bit linear. This commit adds this
exception.
Similarly to other export dialogs, we don't consider anymore metadata or
profile writing as being advanced options. Since these were the only
options shown in our current WebP export dialog, I removed the expander
altogether and moved everything out.
See also commit 540cfa9611.
Profile and output linearity decision was doubled as save_layer() and
save_animation() and I realize that I forgot to update the
save_animation() one in earlier commits.
To avoid code copy-paste and divergence, I added an internal
webp_decide_output() function which I use in both aforementionned calls.
Same as other formats, we make sure that an explicitly set profile TRC
is always followed. When no profile is set, we always export as sRGB
when there is precision downsizing to avoid shadow posterization, since
WebP stores 8-bit max per channel (as far as I know, or at least as far
as we implemented it in our plug-in).
We only take the storage format into account when it is 8-bit linear
with profile export. In such case, we avoid conversion from 8-bit linear
to 8-bit sRGB.
This is different to TIFF export for instance, where we fallback on
following storage format TRC as we are able to export all sort of
precisions, hence with minimum quality loss.
Same as we did for PNG and JPEG, we want to always export data with the
TRC of a profile manually assigned, and in particular NOT the curve of
the storage in GIMP (i.e. you may work on 32-bit linear, yet if you
assigned a sRGB TRC profile, this is what you should export). The
storage format will only dictate the exported data TRC when writing out
the default profile (i.e. no explicit profile assignement).
As a last case, when no profile is saved, we always export as sRGB.
As for the export precision, we always follow the storage one's, except
sometimes for 8-bit images. We promote 8-bit images to 16-bit if and
only if the storage does not match the export data linearity, to avoid
too much quality loss during format conversion.
In file-tiff, when not saving layers, avoid duplicating the image
to create the merged version if it's already been duplicated, and
make sure to delete the duplicated image otherwise.
Similar to JPEG export (commit c5f7bac2ba)
as discussed with Ell. GIMP should follow and save as-is any *assigned*
profile. We only make a decision about whether to convert from storage
precision to another format when the profile is the default GIMP one.
Picked from commit 72c5d24fe9.
Some changes may have to happen later on the master code as the space
invasion changes a bit how default profiles are handled.
GIMP should not convert assigned profile to sRGB just because we stored
as linear on the XCF. In other words, we should not look at the image
precision to decide whether to export as linear (previously only 8-bit
linear images), but at the profile TRC. There are basically 3 cases:
(1) We don't save a profile, then convert to sRGB whatever the source
precision (because readers would assume sRGB for a no-profile jpeg).
(2) We save the default profiles: convert to sRGB because it's usually
a better choice for 8-bit formats and even working at 32-bit float
*linear* doesn't mean you want to export as 8-bit int *linear*. As the
image creator made no explicit export choice, we make an acceptable
default one.
(3) We save an explicitly assigned profile: keep the profile TRC, don't
convert!
Note that this apparently won't work perfectly right now, as GIMP
replaces the original TRC with the linear default TRC when converting to
linear. So the expected TRC is lost in such case when you have not
explicitly reset the correct profile. Yet this is on GIMP side and this
part of the issue should be fixed with the space invasion merge. For
now, this is how the plug-in should work.
This is based on my late discussion with Ell. Please everyone, and Ell
especially, review! :-)
(cherry picked from commit c5f7bac2ba)
The export code was checking the existence of a profile variable which
was never set. In other words, it seems we were always converting TIFF
pixels to non-linear, even when we were also exporting a linear profile.
Note that is not useful anymore to check profile existence as we now use
the effective profile (which always exists). So we just have to check if
the "save profile" option is on.
... 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.
... 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.
In an animated WebP, chances that layers/frame have the same size is
high. It is uneeded to free then malloc again a buffer at each frame,
unless we need more allocated memory.
This is probably not so significant, but still feels nicer.
Spyrogimp has been rewritten in Python with more features.
Note: this commit should not be backported to gimp-2-10 since we will
keep the old plug-in around (in case its API is used by older scripts in
particular). But let's turn over a new leaf with future GIMP 3 and only
keep the new plug-in.
This argument should actually say "Do not store premultiplied channel
values", which is what the TIFF spec calls "Unassociated alpha" (vs.
"associated alpha" when values are stored premultiplied by alpha).
Now I can see where the current description is coming from, which is
that any color with alpha 0 (totally masked) ends up as RGBA value (0,
0, 0, 0), in other words, the color information is completely lost. Yet
this label is not very helpful to understand what the checkbox really
does. I decided to not just change it altogether as people would have
gotten used to this for years, but at least adding completary
information in API and tooltip in GUI.
(copied from 18a2f576bb instead of
cherry-picking since differences in the ui file was making
cherry-picking over-complicated for just one line)
Not sure what this @image_types parameter of gimp_install_procedure() is
used for. Exporting was working find with INDEXEDA image even when not
advertized by this function. Let's update this anyway.
(cherry picked from commit a0a7ead13f)
Commit dc069e424a removed the
assumption that 1-bpp PCX files are B&W, in favor of using the
provided palette, which is (supposedly?) the correct behavior.
However, there are evidently B&W files that do not specify a
palette, resulting in an all-black image (i.e., a 2-color indexed
image, whose both palette entries are black). Since other
software, including older versions of GIMP, load such files
"correctly", let's fix this by falling back to a B&W palette when
the provded palette is uniform.
but only the actual saving code, not the export magic and dialog.
Add new internal procedure file-pat-save-internal which is not
registered as a file procedure and always works non-interactively on
the passed arguments and only saves the passed drawable. Use the new
internal procedure from the file-pat-save code and remove all file
writing code from the plug-in.
This way all pattern file writing code duplication is killed, while
the whole export mechanism is completely unchanged.
We currently have brush and pattern I/O code in both the core and
plug-ins. This commit starts removing plug-in code in favor of having
one copy of the code in the core, much like XCF loading and saving is
implemented.
Add app/file-data/ module with file procedure registering code, for
now just with an implementation of file-gbr-load.
Remove the file-gbr-load code from the file-gbr plug-in.
In pygimp/plug-ins/Makefile.am, fix the rule for the generated
plug-in files, so that they're re-copied to the build dir upon
changes to the source plug-in files.
This plug-in failed to cross-build because these macros were not defined
in the `float.h` of my MinGW64 environment (and they are used in some
ilmbase headers). Just define them ourselves if they are absent. I do
this only on MinGW environment because these should really be defined on
Linux (and other UNIX-like, I guess?) and if they are not, we may have a
bigger issue.
When initializing a pygimp plug-in derived from gimpplugin.plugin,
only pass the plug-in's init() and quit() functions to gimp.main()
if the plug-in actually implements them, instead of passing the
default NOP versions. This avoids plug-ins that don't implement
init() from being registered as having an init function, causing
them to be run at each startup.
... from menus.
The script-fu version is still available through pdb (for scripts) and
even in the action search. But in menus, only the new Python version
will be shown. Also update the description and name of the old version
to make clear it is deprecated in favor of the new plug-in.
Finally rename the new version to simply "plug-in-spyrogimp" (dropping
the "-plus" part as we should consider it as a replacement rather than
as another plug-in, which the "plus" would imply). Anyway the old one
was called "script-fu-spyrogimp", so there is no name clash.
While at it, do some trailing whitespace cleaning in the new plug-in.
(cherry picked from commit 8729f9a662)
Comment by reviewer (Jehan):
This was submitted through gimp-developer mailing list, by the same
author as the original Spyrogimp in script-fu, but this time in Python.
It does more than the original plug-in, with some automatic preview (by
drawing directly on a temporary layer, not as a GEGL preview), and using
the current tool options (current brush, etc.). The new API is similar
yet different. The much evolved possibilities makes that I don't think
it is worth trying to map 1-1 the new API to the old one, so I just let
the old plug-in next to the new one, with a different name.
Note finally that the author also contributed a new Spyrograph operation
to GEGL, yet with the comment: "The GEGL spyrograph operation is very
basic, and untested from gimp. I intend to keep developing it, since I
thought that on-canvas interaction would be very user-friendly. However,
I am not sure I will be able to get it work in a way that makes the
on-canvas interaction interactive enough.
Even if I do, it will not do what the Python plugin can do. It will be
much more basic."
So let's just integrate this evolved version of Spyrogimp for now. :-)
See: https://mail.gnome.org/archives/gimp-developer-list/2018-September/msg00008.html
(cherry picked from commit 529583430d)
Several en_GB to en_US.
Also "Show a preview of the transform_grided image". "grided" should be
"gridded", but I also have a problem with the underscore. Should it be
"transform-gridded"? Even so, does it really make sense?
I chose to just read "Show a preview of the transformed image", which I
think is simpler and the most understandable (we don't need to leak the
implementation with a transform grid into the human read text IMO). If
anyone think that was not the right choice, feel free to propose
otherwise.
Thanks to Bruce Cowan for noticing these.
I am unsure of the problem, but it is fixed by using
poppler_document_new_from_gfile() instead of giving the contents of a
GMappedFile to poppler_document_new_from_data().
Using GFile is anyway usually prefered so I don't dig up more and just
make this change.
As correctly spotted by Royce Pipkins, the buffer for the drawable's
pixel lines was too small.
Also fix the plug-in to hardcode "R'G'B'[A] u8" so it won't misbehave
on high bit-depth images, and make it work on all sorts of drawables,
not only "RGB*" (it will still always export RGB images).
None of our load plug-ins have such a checkbox, so this is not
consistent. Moreover one you uncheck it, you just can't get back the
dialog until next GIMP restart. That's very bad usability.
This commit fixes the following error:
> attempted to install a procedure with a full menu path as menu label,
> this is not supported any longer.
Instead, if we want new items in menu, we should use
gimp_plugin_menu_register(). I add the calls, yet comment them out,
since I don't think we want these various conversion calls into the
provided filters. The proper way for data conversion should be through
babl/GEGL.
Add flag GIMP_METADATA_SAVE_COLOR_PROFILE to GimpMetadataSaveFlags and
initialize it from gimp_export_color_profile() in
gimp_image_metadata_save_prepare().
Adapt all plug-ins to use the bit from the suggested export flags and
pass the actually used value back to
gimp_image_metadata_save_finish().
This changes no behavior at all but creates hooks on the libgimp side
that are called with the context of an image before and after the
actual export, which might become useful later. Also, consistency
is good even though the color profile is not strictly "metadata".
...export dialogs
Remove the "Advanced" expander and have all options in plain sight.
Issue #701: Add a "Save color profile" toggle and always honor it.
by using gimp_image_get_effective_color_profile() instead of just
_get_color_profile(). Don't look at the preference setting because PSD
should behave more like "save" than "export" and save everything.
...export dialogs
Remove the "Advanced" expander from the PNG export GUI and generally
clean up the dialog layout.
Issue #701: Add a "Save color profile" toggle and always honor it.
...export dialogs
Move most stuff out of the "Advanced" expander, only nerdish encoding
options are left there.
Issue #701: Add a "Save color profile" toggle which honors the default
value configured in preferences and always saves the profile when
enabled.
As I did on app/, finalizing an output stream also implicitly flushes
and closes it. Hence if an export ended with an error, we'd end up with
incomplete data file (possibly overwriting a previously exported image).
Only 2 plug-ins I haven't fixed yet are file-tiff-io and file-gif-save.
The later one don't even clean up its memory (which somehow is good here
as at least the output stream is never finalized hence sane files are
not overwritten in case of errors). As for the former (TIFF plug-in), it
doesn't even seem to have any error control AFAICS, apart from printing
error messages on standard error output.
Nothing said what was going to be the order of the page, except by
testing. Now there will be an explicit text, which will be automatically
updated when checking the "reverse order" box.
Commented out the inactive plug-ins registry: no point linking to a dead page.
Added links to the roadmap page, main wiki page, and the bug tracker. Placed
the link to the bug tracker one level up from '<Image>/Help/GIMP Online'
to make it more visible.
... only shows the color (and nothing else) when "Convert bitmaps to
vector graphics where possible" was set.
This is because gimp_drawable_histogram() only checks selected pixels.
So let's make sure we work on a duplicate of the image so that we can
safely remove the selection before processing the export.
(cherry picked from commit 679e341285)
Add line data padding when necessary.
Additionally I realize we should convert to little-endian after checking
the bytesperline oddness (this bug was most likely unnoticed until now
as most desktop proc are little endian now anyway).
Use the default APIs using GimpRGB and GimpHSV structs instead.
This also changes/fixes the colors in all affected plug-ins which were
broken/restricted in hue range ever since the _int() functions were
changed from a 0..255 to 0..360 hue range 15 years ago in commit
d93c2f61c8.
Add missing fclose invocations and fix copy-paste issue.
This issues has been discovered by coverity scan proceeded by Red Hat.
Fixed some mistakes in the patch and added more fclose() (Mitch)
(cherry picked from commit 56c8f8320d)
script-fu used to query the information of every PDB procedure on
startup, in order to get the number of parameters for each
procedure. This was done so that nullary procedures were defined
in such a way as to accept (and ignore) any number of arguments
(and at least one of the scripts we ship relies on this behavior).
However, this requires expensive back-and-forth communication with
the main GIMP process, which notable slowed down script-fu's
startup, and had a non-negligible impact on GIMP's startup time.
Instead, avoid querying procedure information, and implement the
special behavior for nullary procedures at call time. We do this
by defining, in addition to the "strict" gimp-proc-db-call
procedure, a "permissive" -gimp-proc-db-call internal procedure,
and using the latter to call the predefined PDB procedures.
After Dirk Farin had another look in the specs, it turns out that "mif1"
is actually allowed as major brand for HEIF. Also adding "msf1" which is
the equivalent for image sequences.
Just looking for "ftyp" would also match other ISOBMFF files (.mov or
.mp4 files for instance). These are the possible 4-byte "brand" code
which can follow "ftyp", as listed by Dirk Farin from libheif.
I add the "mif1" brand, as I encountered some files using this magic
(even though this should normally not be valid apparently, yet the file
loaded fine in GIMP).
This is not perfect as the standard allows potentially very big box
headers, in which case 8 bytes (the "largesize" slot) may be inserted
between "ftyp" and the brand, as I understand it. But this is actually
unlikely enough to probably never happen (the compatible brands list
would have to be huuuge, as it looks like this is the only extendable
part in a ftyp box). So let's assume this just never happens.
See also: https://github.com/strukturag/libheif/issues/83
Adding a magic number for HEIC/HEIF, which would allow to discard
obvious non-HEIC images even with the wrong extension.
Note: it looks like this magic number would also match more generically
other ISO base media file format (ISOBMFF) formats, like .mov or .mp4
files. I am enquiring for better magic but for now, this is better than
nothing.
... provided by RawTherapee's installer (version 5.5+).
See https://github.com/Beep6581/RawTherapee/issues/4783.
This patch required a small change to file_raw_get_executable_path
because the RawTherapee installer is supposed to work without admin
privileges and therefore can't write to HKLM.
Reviewer's note (Jehan): RawTherapee's installer does not add the
registry entry yet. We assume the upstream bug report will end up doing
so (someone has to make the first step!). :-)
This code was originally written by Thomas G. Lane and Todd Newman,
and proposed for inclusion in the Independent JPEG Group's software.
However, that fell through when Tom left the IJG. It was not written by
Marti Maria - Little cms only had a copy of that code.
This code has recently been merged into libjpeg-turbo, so it seems
reasonable to now consider libjpeg-turbo as the canonical source of
these files. However, since the GIMP carries the original version of
the code proposed for IJG's JPEG, and doesn't contain any of the more
recent and minor tweaks made during its inclusion in libjpeg-turbo,
only the original copyright holders (ie., Thomas G. Lane and Todd
Newman) are mentioned.
The relevant license text was lifted from the Independent JPEG Group's
software, similar to the way it's done in Chromium and other users of
this code.
https://gitlab.gnome.org/GNOME/gimp/issues/2119
Do not set the interpreter to `python2` but to whatever was found by the
AM_PATH_PYTHON2() m4 macro.
It looks like the Python2 binary we ship in our DMG may be call "python"
only (without the '2'). Let's just make our code more resilient to
various builds.
I am not sure yet this is the only/actual problem for this issue on
macOS, but this is at least in the right way.
(cherry picked from commit 8f21c9483a)
The python path with directory are generated files and should not be in
the dist. The previous commit was fixing an in-tree `make check` but
this one fixes the `make distcheck` as the dist was packaging the wrong
python files.
(cherry picked from commit 55a7872e1b)
When cross-compiling, I got various linking errors for printf() calls:
> undefined reference to `libintl_printf'
I am unsure why, since this is not recent code, and it used to build
fine with mingw64 compilers (last I cross-built, which is many months
ago). Anyway g_printf() works fine, all necessary libs are already
linked, and it is supposed to be a synonym. So let's just go the easy
way and use g_printf() only.
(cherry picked from commit c49afa4f84)
AM_PATH_GLIB_2_0 m4 macro actually computes this value using
$PKG_CONFIG. Yet $PKG_CONFIG variable is the pkg-config tool looking for
target libraries (not host), hence it would return the executable
`glib-compile-resources` built for the target.
Also using the same variable name invalidates our test: our own
AC_PATH_PROG was never run as the variable was already set. And no
environment variable could override this test anymore either. This is
why I rename the test variable to HOST_GLIB_COMPILE_RESOURCES.
(cherry picked from commit d1d9eb17e5)
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.
It seems I forgot to also install python plug-ins in a subdirectory
(because they are deactivated on master for the time being). I even
found a year-old patch from myself rotting in the tracker, and which was
doing exactly this.
I redid it, improved to fit changes.
... depending on UI language
Use gimp_register_file_handler_priority(), added in the previous
commit, to increase the priority of the merged PSD loader, so that
the non-merged loader is always preferred over it (unless
explicitly chosen), regardless of the UI language.
Michael Natterer