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.
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.
We already had import support through littleCMS. We now use fully
babl/GEGL which makes our code more straightforward and identical,
whichever the input format.
The export support is totally new. It comes with a checkbox to propose
selecting CMYK export and a label displaying the CMYK profile which will
be used.
Now this whole implementation has a few drawbacks so far, but it will be
a good first sample for future CMYK-related improvements to come:
* The export profile I am using is what we call the "simulation
profile" from the GimpColorConfig. This corresponds to the default
"Soft-proofing" profile as set in Preferences. In particular, this is
not the actual soft-proofing profile for this image which might have
been changed through the View menu because this information is
currently and unfortunately unavailable to plug-ins. It is not the
"Preferred CMYK Profile" either, as set in Preferences.
TODOS:
- We really need to straighten the soft-proof profile core concept by
storing it in the image and making it visible to plug-in.
- Another interesting improvement could be to create a
GimpColorProfile procedure argument which would be mapped to a color
profile chooser widget, allowing people to choose profiles in
plug-ins. For an export plug-in in particular, it could allow to
select a profile different from the soft-proof one at export time.
* When we export, if no profile is choosen, babl will use a naive
profile. It would be nice to store this naive profile into the JPEG if
the "Save color profile" option is checked (same as we store a generic
sRGB profile when no RGB profile is set).
* When we import, we just import the image as sRGB. Since CMYK gamuts
are not necessarily within sRGB (some part of the spectrum is usually
well within, but other well outside), other than the basic conversion
accuracy issue, we may lose colors. It would be much nicer to be able
to select an output RGB profile. Optionally if we could create a RGB
color space which is made to contain the whole input CMYK profile
color space, without explicit choice step, it would be nice too.
* I am using babl's "cmyk" format, not the expected "CMYK" format.
"cmyk" is meant to be an inverted CMYK where 0.0 is full ink coverage
and 1.0 none. Nevertheless when loading the resulting JPEG in other
software (editors or viewers alike), the normal CMYK would always
display inverted colors and the inverted cmyk would look fine.
Finally I found a docs from libjpeg-turbo library, explaining that
Photoshop was wrongly inverting CMYK color data while it should not.
This text dates back from 1994, looking at the commit date which
introduced this paragraph. In the 28 years since then, could this
color inversion have become the de-facto standard for JPEG because one
of the main editor would just output all its JPEG files this way?
See: dfc63d42ee/libjpeg.txt (L1425-L1438)
While doing this cleanup, I found at least several other string leaks
in: file-compressor, file-gegl, file-pdf-save, file-raw-data, file-xwd,
jpeg-load, psd-save…
So it's quite worth it!
Note: in file-pdf-save, there is a global variable file_name which seems
to be happily leaked without caring (didn't look in details, but looks
so). I didn't fix this one which will require a bit more in-depth logics
care.
Commit aba721ae68 fixed its intended bug but brought a new: each time
the preview was updated, a new display was created. This fixes this new
bug. Hopefully it's good now!
The port had a slight error, because in gimp-2-10, the display_ID
actually had 3 states: 0 when gimp_export_image() kept the original
image to which we just add a preview layer, -1 when it created a new
image which we wanted to put in its own display, and the display ID
itself when created.
With the new API where display variable is an object, we can only have 2
cases. So I create an additional variable separate_display to make the
distinction.
In PNG, JPEG and TIFF export plug-ins which use the new API, use our new
function to set widget sensitivity.
Note that part of it is similar to commit 6a2910bd3b on `gimp-2-10`,
making "Save GeoTIFF data" checkbox insensitive when there are no such
data available (this feature was late on the main branch as we rushed
for 2.10.24 release).
Similarly to the previous commit, it is not only about using the new
API. I also make sure we do not assume that parasite data is
nul-terminated. In many places, we were just assuming so because these
were supposed to be parasite our code set. Yet these are data input
contained in files which can be wrong for any reason (corrupted file,
bugs, other scripts/plug-ins editing these parasites…). So instead of
assuming string parasites are always correctly formatted, I make sure
they are nul-terminated by passing them through g_strndup() when
necessary.
Not sure why we didn't see the crash earlier and it suddenly shows up
now. Anyway we must delete the exported image **after** calling
gimp_procedure_config_end_export() on it, obviously.
… GimpSaveProcedureDialog.
See issue #6092 and the discussion with Jacob. Basically we are trying
to improve the metadata situation with more edit abilities and
awareness, while in the same time having the export dialogs less of a
mess (the "Comment" input in particular will most likely move to the
metadata editor itself; I left it for now, until the move is done).
The "(edit)" link will basically just run "plug-in-metadata-editor".
Also as a side note: I realized that gimp_pdb_run_procedure() runs
procedures synchronously and wait for a result, which is fine for quick
non-interactive plug-ins, but freezes the calling process otherwise.
Actually even when we want synchronous result, we should allow for GUI
events to be processed (otherwise the OS just thinks the calling export
plug-in is a zombie and proposes to kill it). This API should probably
be improved (and an alternative async version added as well).
This format name is a public facing name for a file format, such as
"PNG", "JPEG", or "C-source". Since it is public facing, the function
recommends to localize it too.
This is an optional name, yet is made mandatory if you want to use
GimpSaveProcedureDialog because it will be used for the dialog title
(ensuring that all support format have a similar export dialog title).
Following this change, gimp_save_procedure_dialog_new() does not ask for
a title anymore (if anyone absolutely wants to set a custom title,
setting the "title" property on the dialog is always possible anyway,
but a generic and consistent title should be set as a default).
Also updating the 3 plug-ins which were already using the now-changed
API.
The various generic metadata options did not have mnemonic in the base
language (US English).
Also add or fix metadata in file-png|jpeg|tiff so that every option has
a unique mnemonic.
This is nearly 600 lines less for basically the same logics! Removed
code is in particular all the GUI code is favor of the new GUI
generation.
I also cleaned a lot of stuff, removing many global variables or ugly
pieces of code. I also removed a lot of redundant code of things which
are now generic, such as handling of "gimp-comment" parasite (this is
now handled by GimpSaveProcedure and GimpImageMetadata) as well as
saving previous run's values (this is also handled generically).
Note that Advanced Options used to be in an expander. For now I chose to
get them immediately visible (still in their own "Advanced Options"
section, but it's now a normal frame, not an expander hidden by default)
since lately we got some input that many "advanced options" in various
dialogs should not be hidden away. So let's try like this for now (even
though it packs quite a lot of options in the same dialog!).
I thoroughly tested, yet that were so many changes that bugs may have
sneaked in. Please anyone, test JPEG export!
Renaming the temporary function gimp_scale_entry_new2() into
gimp_scale_entry_new() now that the original code is entirely gone. This
is now a fully-fledged widget with a nice and proper introspectable API.
I got rid of gimp_scale_entry_set_sensitive(), as we can now use the
generic gtk_widget_set_sensitive(), and I ported the 2 plug-ins using
this function.
I also created gimp_scale_entry_set_value() to set the value (nicer than
setting object properties).
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.
Our currently registered JPEG magics was using possible fields at the
start of the file (JFIF, Exif) in 7th byte. A JPEG provided in #5584 was
starting with yet another field (apparently some Photoshop-specific
field "Photoshop 3.0.8BIM") thus magics detection failed (and since
extension was wrong, the file was sent to another plug-in, hence loading
failed).
Looking further, it looks like the 3 first bytes are actually always
common to all JPEG and are the right magics/signature for a JPEG. These
3 bytes don't seem to be used by other formats as well according to my
research, which means we should not have false positives either. So
let's switch to this magics 0XFFD8FF at byte 0.
This commit just changes our saving API (i.e. the GimpSaveProcedure
class) to take an array of drawables as argument instead of a single
drawable.
It actually doesn't matter much for exporting as the whole API seems
more or less bogus there and all formats plug-ins mostly care only
whether they will merge/flatten all visible layers (the selected ones
don't really matter) or if the format supports layers of some sort. It
may be worth later strengthening a bit this whole logics, and maybe
allow partial exports for instance.
As for saving, it was not even looking at the passed GimpDrawable either
and was simply re-querying the active layer anyway.
Note that I don't implement the multi-selection saving in XCF yet in
this commit. I only updated the API. The reason is that the current
commit won't be backportable to gimp-2-10 because it is an API break. On
the other hand, the code to save multi-selection can still be backported
even though the save() API will only pass a single drawable (as I said
anyway, this argument was mostly bogus until now, hence it doesn't
matter much for 2.10 logics).
This gives a big cleanup in the meson.build files of the plug-ins.
It's also quite a bit more maintainable, since anything that changes in
libgimp's dependencies, linkage, ... doesn't have to be copy-pasted into
each plug-in.
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.
jpeg-save.c:56: warning: "DEFAULT_QUALITY" redefined
56 | #define DEFAULT_QUALITY 90.0
|
In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
from C:/msys64/mingw64/x86_64-w64-mingw32/include/rpc.h:16,
from C:/msys64/mingw64/x86_64-w64-mingw32/include/objbase.h:7,
from C:/msys64/mingw64/x86_64-w64-mingw32/include/shlwapi.h:16,
from C:/msys64/mingw64/include/jmorecfg.h:19,
from C:/msys64/mingw64/include/jpeglib.h:31,
from jpeg-save.c:33:
C:/msys64/mingw64/x86_64-w64-mingw32/include/wingdi.h:1140: note: this is the location of the previous definition
1140 | #define DEFAULT_QUALITY 0
We now have both variants, one returning a GList, and another
returning an array. Turns out that while a list is often nicer,
sometimes a random-access array really keeps the code much simpler.
Adapt all plug-ins, and clean up a bit (like use g_list_reverse() once
instead of iterating the list reversed).
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.
Basically this commit makes sure that all return values that are marked
as "Returns:" also have a `(nullable)` annotation if it is mentioned on
the same line that NULL can also be returned.
This will prevent a few problems in GObject-introspection.
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.
... 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.
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)
... 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).
Jehan