The Lua API is undergoing changes in darktable master. I've fixed the lua-scripts repository as I've made
changes, but I forgot about the collateral damage.
Attached is a fixed version of file-darktable-export-on-exit.lua which should be good for darktable 3.6 and
beyond.
Fixes#6421
PDF exporting had no progression. In particular when exporting a PDF
with more a hundred pages today, it took maybe 20 secs without any
progression status, which is annoying.
Limitations:
1. When exporting as multi-images, we reset to 0 at each image. I am
actually not sure if this is the expected behavior.
2. I am updating the progression per top layer, not doing finer grained
progression steps. An extreme case would be a single top layer group
with many children layers inside. Yet I wanted to avoid too much
progression updates for the normal cases.
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.
Now when a gAMA chunk is set on an imported PNG (and if there is no
profile attached), an equivalent profile is created out of the gAMA
chunk. So the displayed image looks like it is supposed to.
On export, the generated profile should simply be saved together in the
PNG file. If not, the sRGB chunk is set anyway (and also an equivalent
gAMA/cHRM as recommended in the specs).
So basically we now have a proper support of the gAMA chunk, from import
to export, and display within GIMP takes this metadata into account
appropriately (in the shape of a generated equivalent profile).
Therefore it looks to me keeping the option is redundant. It is even
confusing (because it's actually hard to understand exactly what this
data is about, even our documentation about this metadata seems to be
wrong) hence possibly dangerous if someone thinks it is important,
checks the box, which would override other data or simply create
irrelevant or contradictory metadata.
So let's just remove this option. Development releases are the right
places anyway for people to notice this change and come to us if we
missed some usage regarding this option.
See also #5363.
The openraster plug-in uses the png plug-in in non interactive mode
to load and save layers. With a lot of layers we get a lot of
flashing popups because of the progress dialogs.
When it is called in non interactive mode there should not
be a need for progress dialogs so let's disable them in
that case.
The Openraster plug-in calls file-png-load and
gimp-file-load-layer but didn't check if the result
was SUCCESS. Even though I haven't seen any
failures let's improve error checking by adding
a check for a correct result.
The current openraster specification only has a limited
number of layer modes. Let's improve things a little bit
by mapping both the current and legacy layer modes
to the same openraster composite-op where available.
For the other layer modes we could examine what the
closest composite-op is, or add a GIMP specific op
(which is what Krita seems to do). For now we set
all these to the openraster equivalent of NORMAL.
Let's use the non legacy layer modes when importing/exporting
openraster images. That way we are more likely to be able to
import the correct layer modes since openraster only has a
limited number of layer modes defined.
This feature adds new 'Load in reverse order' toggle box to allow
selection of order of PDF pages before importing them as a layers or
images.
Adds new bool parameter 'reverse-order' to Non-interactive mode.
Order of parameters was also changed from (password, n-pages, pages)
to (password, reverse-order, n-pages, pages)
This commit fixes the issue when requested page width/height was
not honored because DPI resolution value was constrained to whole
integer numbers only.
PNG has support for profiles, which is the state-of-the-art way to
handle color management nowadays. But it also had some very basic color
management based on a gAMA chunk (for the gamma) and a cHRM chunk
(primary chromaticities).
We don't have a core concept with just these and don't want to walk
backward anyway, but we can easily make basic RGB profiles from these.
This is what this commit is about. It generates profiles at import which
were not actually inside the image, but only represented by these 2 PNG
chunks. What gives it away is that GIMP will propose to convert/keep the
profile at start (unless configured otherwise, as any profile), and the
profile name will specify it is a profile generated from PNG chunks'
values. One can even discard the profile later (if you didn't convert),
so it gives a solution if somehow these metadata were not proper.
darktable GUI is "mangled" when opened from GIMP for a reporter. There
was already some debug info outputted (when running with DARKTABLE_DEBUG
environment variable). Adding the environment list (and some separation
titles to make it easier to distinguish what is what). Hopefully it will
help debugging.
See #6195 and https://github.com/darktable-org/darktable/issues/7402
We were not handling all possible record sizes for mask info and
in case it was an unknown size we set everything to 0 instead
of reading the parts we do recognize.
Let's make it more flexible by reading the parts we do know
about and skip the remaining data if any.
Also added a few more g_debug statements to make it
easier to check some values when needed.
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.
Commit 01e1587ec1 had directly edited the Makefile.am, which was wrong.
This file is generated by plugin-defs.pl. Add the proper dependencies
for file-heif and regenerate the Makefile.am.
When a profile is set, we should not set the sRGB chunk, because it
would be a contradiction. But when we don't set the profile, then our
code explicitly saves as sRGB. So let's add the sRGB chunk.
Also when we do so, let's also set the relevant gAMA and cHRM chunks
corresponding to sRGB as recommended by the PNG spec:
> An application that writes the sRGB chunk should also write a gAMA
> chunk (and perhaps a cHRM chunk) for compatibility with applications
> that do not use the sRGB chunk. In this situation, only the following
> values may be used: […]
This is why I use png_set_sRGB_gAMA_and_cHRM() and not just
png_set_sRGB().
See also discussions in #5363.
When testing for the presence of extra channels we were not taking into
account all values of TIFFTAG_PHOTOMETRIC causing incorrect messages
that we had a non conformant TIFF without ExtraSamples field.
Since the same test is used twice I separated the code into a new function
and also added another related function to have similar code grouped
together for easier maintenance.
GIMP was exporting certain BMP images with 1, 4, 8 and 24 bpp
with an incorrectly set value of BI_BITFIELDS for compression,
see issue #6144.
According to the specification this is not supported but testing
shows that many image viewers and editors load these
images correctly.
Since allowing these unsupported values for bpp does not
seem to have any negative side effects and is easy to
implement let's add this.
The Microsoft specification for BITMAPV5HEADER says that
BI_BITFIELDS is valid for 16 and 32-bits per pixel, but we
were also using this flag for other values of bpp when
no rle compression was used.
Since this specification doesn't mention 24 bpp or other
values use BI_RGB instead.
Information in issue #6200 revealed that 0 as default value for
the blue channel is a lot more common than 255 so let's use
that instead. The discussion and testing revealed no negative
effects for the other formats that use the same code to
initialize the memory to read blocks of image data.
Since older versions of our GIMP dds file exporter incorrectly
saved BC5 dds images with the red and green channels
swapped we should fix that. Since the exporter already
wrote the plug-ins version number and that it is written by
GIMP we can check for these incorrect images.
To enable that we increase the plug-ins revision in this
commit and swap red and green channels for images
that have an older version number and are of the
correct type.
… org.freedesktop.portal.Desktop (X11 only).
If we don't set this parameter appropriately, the created dialog is not
modal/transient relatively to the main GIMP window. This is especially
annoying because in my tests (GNOME shell), the screenshot dialog would
appear behind GIMP window, which makes it feel like broken behavior.
Note that the supported handles are X11 only so far. We'll need to
generate the appropriate Wayland handles too (created from xdg_foreign
protocol).
Today I have only re-tested the GNOME implementation (in particular not
the KDE one) of the portal API org.freedesktop.portal.Screenshot but I
assume it is similar because the dbus function does not provide any
useful options anyway. This is why the portal comes with its own dialog
providing the various common screenshot features (delay, window picking,
area selection, etc.). Showing our dialog first is therefore redundant.
Also I updated setting the monitor profile only in the case where the
loaded image result from the portal did not have an embedded profile. To
be fair, the GNOME implementation at least does not embed a profile to
this day. So this is only for the future case where they will finally do
the right thing and embed the display profile (or for other desktops'
implementations where they maybe already do the right thing).
This was true in the "old world" where X11 support being built-in meant
that X11 screenshot would be usable. Now we must not only check it is
built, but also that we are actually running under X11. Otherwise with a
Wayland compositor, screenshot would fail. Also it meant that the
Freedesktop portal was never tried if both X11 and Wayland support were
built-in.
If we were loading multi page tif images as layers then only the tif pages
that had a color profile attached would get set as linear (and each tiff page
can have a color profile). Since most of the time only the first page has a
color profile this caused us to load linear tiff pages incorrectly.
Also we were overwriting the color profile if there was more than one since
GIMP can only load one per image. Instead of using the last one we see
use the first one and notify if we encounter more than one.
… 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.
Realtime parameter is set for AOM encoder
when Fast encoding speed is selected by user.
Ability to set pixel format (YUV444, RGB)
is enabled for >= libheif 1.10
to avoid issues in older versions.
This fixes various similar warnings:
> file-xmc.c:2276:53: warning: ‘save_rgn.height’ may be used uninitialized in this function
Note that I have not looked in details, but it would seem that these are
actually initialized by get_cropped_region() which uses goto-s quite
extensively, so obviously it's hard to follow (for humans as well as for
the compiler). So let's just assume there is no code error and let's
just add default initialization to silence the compiler.
Per polls on Twitter, Reddit, Patreon and Tipeee, most people were
willing to drop this plug-in as not being relevant anymore (247 for
dropping and 63 for keeping it, so nearly 80% out of 310 participants).
So let's move it to gimp-data-extras allowing it to still have a
possible life, and who knows, maybe to even evolve.
See also corresponding commit beffc6b to gimp-data-extras repository.
This fixes issue #6065 and part of #2680.
Sometime after GIMP 2.8 loading of 2 and 4 bit tif images,
both grayscale and indexed, got broken.
I added routines for handling 2 and 4 bit tifs based on
the handling of 1 bit images.
When not creating an image, we were always returning with status
GIMP_PDB_EXECUTION_ERROR even though it might have been GIMP_PDB_CANCEL
(which is not handled as an error, this is user choice, hence no dialog
pops up).
William Ferguson