Also avoid global variables when possible. We can just use the data
variable of EnumDisplayMonitors() which will be passed on to the
callback. This is not perfect yet since rectScreensCount is still
global, but let's go for it for now.
Mostly warnings about wrong types for some function parameters.
There is still a single warning remaining about ignoring the #pragma
macro, but I am not sure what to do about this warning. Apparently it is
something specifically for use with Visual Studio. We don't need this,
but since the contributor uses it, let's keep it.
This was lost in commit 966843564d. It's not a big deal since this code
path would only happen when the capture using magnification API fails,
yet we may as well make it perfect.
Also taking the opportunity to change the return type to gboolean for
the various capture functions (though it is technically the same,
semantically we were returning success boolean).
And removing a comment which had been duplicated and left at a the wrong
place.
This fixes bugs 793722 and 796121.
In particular it fixes:
- Single-window screenshot when partly off-screen or covered by another
window.
- Screenshots when display scaling is not 100%.
When working on the current image, enclose the script actions in an undo group.
When working with a copy of the image, disable the undo stack of the new image
at the beginning of the script and reenable it at the end.
Current code was only taking into account cancelation, so we could end
with weird plug-in return:
> HEIF/HEIC plug-in returned SUCCESS but did not return an image
Instead properly set an error status, and echo back the error from the
plug-in or libheif.
Use gimp_image_{freeze,thaw}_layers(), added in the previous
commit, to suppress updates to the Layers dialog while constructing
the decomposed layers, which significantly speeds up the operation
if the dialog is mapped.
Thanks a lot to Dirk for contributing this, added him to AUTHORS.
Import the code from https://github.com/strukturag/heif-gimp-plugin.git
as of today. Merged the files into a single-file plug-in. Changed
the code a lot to match our coding style, but only formatting,
no logic changes.
Still uses deprecated GimpDrawable API and no GIO, but I wanted to do
actual code changes separately from the initial import. Also disabled
metadata support because updating that to GimpMetadata was too much
for the initial import.
In the file-psd plug-in, ignore the 'irrelevant' flag of layers
when loading PSD files; in particular, don't hide such layers
unconditionally. The 'irrelevant' flag seems to indicate that the
layer's content can be entirely derived without using the layer's
pixel data, and not that the layer itself it irrelevant.
Some locales (like German) use ',' as the decimal separator, so using
printf like functions to output a float value fails when the result
should always use '.'. Since there are only two distinct possibilities
we just write the string representation and be done with it.
Last commit caused -xobjective-c to be passed during linking on
Mac, causing object files to be treated as source files. Add a
-xnone flag to AM_LDFLAGS, canceling the effect of -xobjective-c.
Additinally, add a -xobjective-c++ flag to AM_CXXFLAGS, so that we
can use Objective-C in C++ files on Mac, if we ever need to.
On Mac, pass -xobjective-c to the compiler through AM_CFLAGS, not
AM_CPPFLAGS, so that it's only used for C sources, and not C++
sources. In the latter case, it clashes with the -std=... flag,
spewing an error. Thanks, Partha :)
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.
Some tag data is hold in GtkEntry, other in GtkTextView, which are not
parent to each other. Previous checks were wrong and resulted in
"invalid cast from 'GtkEntry' to 'GtkTextView'" WARNINGs (followed by
many CRITICALs because of this first error).
Also properly free the data returned by gtk_text_buffer_get_text() which
is allocated (unlike strings returned by gtk_entry_get_text() which must
not be freed).
Our composite modes don't correspond directly to the Porter-Duff
operators after which they're named, and these names aren't too
descriptive anyway.
Rename the composite modes as follows:
Source Over => Union
Source Atop => Clip to Backdrop
Destination Atop => Clip to Layer
Source In => Intersection
Update relevant code, including UI text, enumerator names, function
names, and action names.
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.
Thomas Manni