- This is unneeded in all import procedures. See previous commit. Note though
that this is not because of a change in previous commit. This was already
useless previously. The file set with this PDB function was overridden by the
core anyway (i.e. even before the previous commits).
In app/file/file-import.c:file_import_image(), the imported file is correctly
set (so there is no need to set it from plug-in, which anyway libgimp's
gimp_image_set_file() was not doing) and the XCF file is reset to NULL
(rendering the call to gimp_image_set_file() in a GimpLoadProcedure useless).
- Similarly, this is a useless call in export procedures because
app/file/file-save.c:file_save() overrides such call too. I could only see one
such case for JPEG export, which was quite useless.
- Finally in other types of plug-ins, setting a non-XCF file extension was
interfering with the save feature (similarly to commit e6e73e14c7). I only
fixed the screenshot implementations doing such a thing.
- I left a few usages which will have to be looked at more in details later.
This is the consequence of previous commit. Plug-ins' label and
documentation are now localized before sending these data to GIMP core.
In other words, we replace N_() macros with basic gettext calls.
I guess I missed this one as I was not building it locally.
Fixes:
> In file included from ../plug-ins/common/file-jp2-load.c:86:
> ../plug-ins/common/file-jp2-load.c: In function ‘jp2_class_init’:
> ../libgimp/stdplugins-intl.h:42:22: error: ‘set_i18n’ undeclared (first use in this function)
Hence avoiding the stderr messages. These are going to be localized with
centrally installed catalogs "gimp*-std-plugins", "gimp*-script-fu" and
"gimp*-python".
We now handle core plug-in localizations differently and in particular,
with kind of a reverse logic:
- We don't consider "gimp*-std-plugins" to be the default catalog
anymore. It made sense in the old world where we would consider the
core plug-ins to be the most important and numerous ones. But we want
to push a world where people are even more encouraged to develop their
own plug-ins. These won't use the standard catalog anymore (because
there are nearly no reasons that the strings are the same, it's only a
confusing logic). So let's explicitly set the standard catalogs with
DEFINE_STD_SET_I18N macro (which maps to a different catalog for
script-fu plug-ins).
- Doing something similar for Python plug-ins which have again their own
catalog.
- Getting rid of the INIT_I18N macro since now all the locale domain
binding is done automatically by libgimp when using the set_i18n()
method infrastructure.
Orientation is now handled by core code, just next to profile conversion
handling.
One of the first consequence is that we don't need to have a non-GUI
version gimp_image_metadata_load_finish_batch() in libgimp, next to a
GUI version of the gimp_image_metadata_load_finish() function in
libgimpui. This makes for simpler API.
Also a plug-in which wishes to get access to the rotation dialog
provided by GIMP without loading ligimpui/GTK+ (for whatever reason)
will still have the feature.
The main advantage is that the "Don't ask me again" feature is now
handled by a settings in `Preferences > Image Import & Export` as the
"Metadata rotation policy". Until now it was saved as a global parasite,
which made it virtually non-editable once you checked it once (no easy
way to edit parasites except by scripts). So say you refused the
rotation once while checking "Don't ask again", and GIMP will forever
discard the rotation metadata without giving you a sane way to change
your mind. Of course, I could have passed the settings to plug-ins
through the PDB, but I find it a lot better to simply handle such
settings core-side.
The dialog code is basically the same as an app/dialogs/ as it was in
libgimp, with the minor improvement that it now takes the scale ratio
into account (basically the maximum thumbnail size will be bigger on
higher density displays).
Only downside of the move to the core is that this rotation dialog is
raised only when you open an image from the core, not as a PDB call. So
a plug-in which makes say a "file-jpeg-load" PDB call, even in
INTERACTIVE run mode, won't have rotation processed. Note that this was
already the same for embedded color profile conversion. This can be
wanted or not. Anyway some additional libgimp calls might be of interest
to explicitly call the core dialogs.
and in an attack of madness, changes almost all file plug-in
code to use GFile instead of filenames, which means passing
the GFile down to the bottom and get its filename at the very
end where it's actually needed.
And always pass URIs to all file procedures, the ones what didn't
register as "handles remove" will only ever get local file:// URIs.
Change all file plug-ins (also legacy ones) to expect URIs instead
of filenames, and convert to local paths in the plug-in.
The wire protocol should now be almost 100% clean of non-UTF-8 strings.
...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.
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.
Exchanging with OpenJPEG developers and searching more on the topic, it
seems that YUV is more often refered to as YCbCr. Wikipedia says:
> typically the terms YCbCr and YUV are used interchangeably, leading to
> some confusion. The main difference is that YUV is analog and YCbCr is
> digital
As for eYCC, I am told this is extended YCC. It seems this is refered as
xvYCC (I really can't find much under "eYCC"). So let's rename it too.
Hopefully I made no mistakes!
JPEG 2000 codestream doesn't have a header and guessing the color space
in particular is not foolproof (especially when 3 or 4 components, which
can be many spaces). Therefore the need of a parameter on the API.
Note that JP2 images should always have the color space information. In
interactive mode, I try to be a bit flexible to salvage broken JP2 with
no color space information in the header, but I am not adding a
parameter in file-jp2-load() (on purpose, since we are not going to add
in the API a parameter for a case not supposed to happen with properly
encoded files).
JPEG 2000 codestream (.j2k/.j2c) are only compressed code stream data,
without header. In particular we don't have color information, such as
the color space. So we need to open a dialog asking to set the color
space in interactive mode.
Note: according to OpenJPEG developers, a JP2 image (not codestream)
should always have a color space defined in its header. But just to be
flexible, the same dialog may get raised as well if we try to load a JP2
with no valid color space defined in header and no ICC profile embedded.
Maybe if such a thing happened, it means the image is corrupt, yet we
may as well try and salvage it anyway.
Note 2: I also removed a weird test which was setting some images as
being YUV color space by mistake. This actually fixes bug 794413 as a
side effect.
Even though I haven't seen working samples with this extension,
according to some references, this is a common extension for compressed
JPEG 2000 code stream. Also our old plug-in was listing this extension,
so let's do so now as well.
To this day, the only 2 extensions we used to list in the JasPer-based
plug-in and not in the OpenJPEG one are .jpf and .jpx (JPEG 2000 Part-2)
since OpenJPEG does not have support yet. But actually I think the old
plug-in may have simply been "lying" since JasPer website says the
library is meant to implement JPEG-2000 Part-1 standard.
So I believe we are now on par (and even better on many aspects) with
the former plug-in implementation based on libjasper.
After moving up the profile extraction, I was running
gimp_image_set_color_profile() with a non-existing image id, which was
obviously wrong. Reorder a bit the operations.
Also try to guess the color space from the profile not only with
OPJ_CLRSPC_UNSPECIFIED but also OPJ_CLRSPC_UNKNOWN images. Indeed I
encountered a case of .jp2 image with no color space in the header, but
with an embedded profile. And unlike the .j2c files I encountered
earlier, the color space was now *_UNKNOWN.
See https://github.com/uclouvain/openjpeg/issues/1103
Current OpenJPEG code only supported the base JP2 container. It now
supports also the JPEG 2000 codestream (which is usually contained
inside other formats, like the JP2 container format, but can also
sometimes be on its own).
The current magics and extension strings were also mixing all kind of
formats. This is now cleaned up a bit.
As explained in the previous commit, the color space is not always
properly declared, in particular with J2K files. If a profile is present
in such a case, try to deduct the color space from this information.
It seems that the color space is not necessarily declared for a JPEG2000
image. From tests, it looks like it especially happens with JPEG2000
codestream (.j2c or .j2k). This variant is apparently mostly designed to
be embedded (from what I read), which may explain why the color space is
not always set (I assume the embedding format would have the color space
information). Mostly a guess.
Rather than just assuming all non-gray images are RGB, do a bit more
robust check and reject unknown formats. Indeed even though I see we
took care of YUV, e-YCC and CMYK images above (and normally either
converted them to RGB or already exited with an error), I can see that
the OpenJPEG library could still return OPJ_CLRSPC_UNKNOWN or
OPJ_CLRSPC_UNSPECIFIED. Let's be thorough and not assume we got a SRGB
here.
Also add the alpha-variant tests inside their parent image type
respective test. This should not change anything by any logics, but
let's not leave anything for chance to strike us.
Finally minor coding style fixes:
- Add a space before "if|for" and parenthese.
- Remove some spaces after parentheses.
- Get rid of 2 trailing whitespaces.
- Align function call parameters, declarations, assignments…
Made plug-in support the RGB and grayscale with alpha.
Comment by Jehan: this makes the original branch work finally usable on
some JPEG 2000 images. Support of the format is not complete yet though
but at least the port to OpenJPEG is now in usable test.
...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.
So the plug-in has the chance to decide whether it wants to trust the
metadata information (e.g. resolution). Also reorder parameters in
gimp_image_metadata_save_finish(). Change all plug-ins accordingly.
Based on original patches from Hartmut Kuhse and modified
by Michael Natterer. Changes include:
- remove libexif dependency and add a hard dependency on gexiv2
- typedef GExiv2Metadata to GimpMetadata to avoid having to
include gexiv2 globally
- add basic GimpMetadata handling functions to libgimpbase
- add image and image file specific metadata functions to libgimp,
including the exif orientation image rotate dialog
- port plug-ins to use the new APIs
- port file-tiff-save's UI to GtkBuilder
- add new plug-in "metadata" to view the image's metadata
- keep metadata around as GimpImage member in the core
- update the image's metadata on image size, resolution and precision
changes
- obsolete the old metadata parasites
- migrate the old parasites to new GimpMetadata object on XCF load
