After the change that allows multiple layers to be selected exporting to
a pattern fails.
Patch this as suggested by Lloyd Konneker by doing the same as for brushes:
do not allow multiple layers, instead only send the first drawable.
Due to differences between Windows and most other platforms Ghostscript
didn't correctly load files with special characters on Windows.
First we needed to make sure that the filenames we use are in utf-8
format and then tell gsapi that we use utf8 encoding.
When exporting to bmp using a script or plug-in we could not set the
parameters use-rle, write-color-space-info, and rgb-format when used
non-interactively.
This is discussed in issue #491. The patch there does not work for master,
so I came up with this.
When exporting a C source file with runtime length encoding, the
C-string's array size does not accomodate for the null byte. However,
GIMP accomodates for the NULL byte in it's NON-RLE export, suggesting
that this has been a mere oversight for RLE.
This can cause at the worst a compile-time error and at least a warning
from the compiler.
For 1-bit BMP export we did not show the save dialog, making it
impossible to change settings interactively.
We enable the save dialog for 1-bit too, making sure to disable RLE, which
is not available for 1-bit.
In addition, also set the RLE config option to false for all cases where
it can't be used.
… GimpUi.ProcedureDialog.new()
The old way is still working and acceptable as far as I am concerned.
Just switching to the recommended (by upstream) syntax to show it works
as expected and as a good example of code.
Our plug-in was not correctly handling DICOM images that use big endian
transfer syntax, which is deprecated.
We add support for that here, add a few g_debug statements to make future
debugging easier, and also return an error when we encounter a transfer
syntax that we can't handle instead of blindly continuing.
… source colors
Reviewer's (Jehan) note: a git blame shows this is a clear bug
introduced in commit 9d19bf2a3e, which was a cleanup patch, and the
BOUNDS() macro was not doing exactly the same thing as the code before
the change.
Added an option for exporting thumbnail in WebP Export dialogbox.
Additionally, introduced a function gimp_procedure_dialog_fill_expander.
The function is similar to gimp_procedure_dialog_fill_frame but allows
adding GtkExpander instead of GtkFrame.
I must have not been awake yet when I pushed the
fix for #6116 because it has two problems:
- Updating cur_progress caused by not editing the
for loop after a copy/paste, found thanks to
Stanislav Grinkov.
- Not using the correct drawable to determine the
drawable_type which I noticed while fixing the
above issue.
These issues are not present in the backported
version for 2.10.
GIF export was not taking into account that there can be
both grayscale layers with and without alpha in an image.
We make sure that the GEGL buffer knows the type of
drawable for the current layer.
We were loading 16-bit per sample SGI images as 8-bit
integer images even though we have had support for
16-bit integer for a long time now.
Changed to use 16-bit integer encoding now. Saw
this request a while ago on the gimp user mailing list.
Instead of only checking for the layer resources Lr16 and Lr32 make it
a loop and use the generic get_layer_resource_header to read all
resources.
We still need to figure out at a later time how to best handle these
resources.
For PSB images certain resources have 64-bit lengths.
Let's handle this transparently by adding a psd_version
parameter and depending on that and the type of
resource we decide if the length to read is 32 or 64-bit.
We also return the total header size. This way the
calling function can use that to determine the
remaining length.
Because we needed to check the signature when
loading the header we remove that check from
the load_layer_resource function since that
would be redundant.
Apparently layer height or width can be negative for certain
PSD layers that have the irrelevant flag set.
We move those checks down until after we have read that
flag and only validate if the irrelevant flag is not set.
Since the 1-bit conversion debug statements causes a huge amount
of info which can cause slowdowns when loading do it only when
explicitly setting it to IFDBG(4).
In certain places in a PSB file we need to read 64-bit
lengths where in a PSD we read a 32-bit length.
To make handling this easier we add a function that
determines if we need to read 4 or 8 bytes and
also handles converting the value from big endian.
Even though the current specs say max is 56 there
are sample files with more channels. Since there is
no reason why we can't handle more let's increase
the maximum to 99 for now.
Not taking a non zero length into consideration caused us to read from the
wrong location in certain cases and then fail loading.
Always use the specified length to go to the correct location. This is not
a guarantee that we will be able to correctly load the image but at least
we won't read wrong data from the wrong location.
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!
in Gimp and Photoshop- "Too many channels in layer: 4907"
To be better able to handle 64 bit offsets we switch to
using GInputStream/GOutputStream and its related
functions instead of using FILE functions like fseek.
In addition we changed several offsets and sizes to
64 bit instead of 32 bit to correctly handle large
image sizes and offsets.
I should probably have split this out in two parts
(the move to GInput/OutputStream, and the
changing to 64 bit variables) but don't feel like
it's worth the trouble at this point.
Exporting to psd could result in very large files which often failed to
load in both GIMP and PS when a group layer with a layer mask
was present.
Reported on our IRC channel with a sample xcf which made it
possible to figure out the problem.
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.
So far all dds images were loaded as 8 bit per channel which makes
sense for most but not all dds formats.
This commit implements loading in 16 bit for "L16" - a 16 bit
luminance channel.
In addition to that we improve security a bit by not assuming
that L16 is the only left over case but instead explicitly
checking the correct value of rmask for L16.
For other cases we now set an error with enough details
to identify the type of DDS image that needs extra
handling.
When a selection exists, we are copying then pasting the selection
contents. In particular, with multi-layer selection, it means pasting a
merged result of the selected layers (like a sample merged but limited
to selected layers).
Yet when no selection exists, with a single layer selected, a cut in
particular would remove the layer fully, then a paste would copy it
elsewhere (in the same image or even on a different image). This was
still working, but not with multiple layers. This is now fixed and we
can now copy/cut then paste several layers (without merge), which is
sometimes a very practical way to move layers (sometimes simpler than
drag'n drop, especially between images).
As a consequence, the PDB function gimp_edit_paste() now also returns an
array of layers (not a single layer).
Let's increase the default size of the metadata viewer a bit.
Ideally we would add some logic to determine the width of
the first column since that one currently depends on the
length of the longest tag. However for now this change
will be enough for most cases.
The round corners script was assuming that the drawable always
was a layer, which is incorrect when a layer mask is selected.
We fix this by always requesting the active layer instead of
active drawable.
We also enable this script for RGB and GRAY with alpha
channel. Although it might not always make sense to
use this script when an alpha channel is present, there
can be use cases where it is perfectly fine.
So let the designer decide if this script is suited or not
instead of GIMP making that judgement.
This fixes the following error when building for Windows:
> error: too many arguments to function ‘mkdir’
On Windows, mkdir() is deprecated, it is an alias for _mkdir() which
doesn't have a mode parameter. The GLib version duplicates the POSIX
signature and is cross-platform (mode is simply ignored on Windows).
Closes: GNOME/gimp#541
Reviewer note: thanks to Stanislav Grinkov for cleaning up and reworking
a bit the patch, such as renaming the procedure to dir-make, as per
Kevin Cozens' review.
Looking at the documentation it is indeed red that should go
in the lowest bits and blue in the highest bits so just
reverse our code for red and blue.
We also update the version of our GIMP DDS plug-in,
this way we can catch and correct RGB10A2 images
written by older versions of our plug-in and correct
them.
Jacob Boerema