"Hold and Modify" ILBM images use control bits to increase the palette
beyond what's stored in the CMAP chunk. This patch checks if
HAM mode is set and then interprets the plane bits accordingly.
As GdkRGBA stores colors as doubles rather than guint16, the assignment
code had to be moved into the ifdef block as well.
Note that this code is only used if X11 is not available on build.
These five plug-ins already used GimpProcedureDialog when I originally
worked on them for !9250. However, their export GUI needs to
use GimpSaveProcedureDialog instead.
Let's make cfitsio an optional dependency, showing up in the final configure
output. The file-fits plug-in will just not be built when the dep is missing.
Switch to NASA-maintained cfitsio library for loading/exporting FITS images.
This allows us to import compressed FITS files (GZIP, HCOMP, PLIO, RICE) in
8/16/32 bit and float/double precision. It also simplifies export code using
the built-in cfitsio APIs.
- Missed a necessary autotools change: forgot to remove ui/Makefile
from configure.ac
- Not all compilers allow declaring variables in a case statement without
putting them in a block, so we add a block now.
Instead of loading the GtkBuilder .ui file we now create all widgets in
code.
Added several support functions to reduce code copy/pasting and making
additional widgets and supporting more metadata easier.
The overall layout should still look the same, with a few exceptions:
- Each notebook page only uses one grid. This makes it possible to align
all data entry widgets.
- Featured Organization and it's code were two treeviews next to each
other. These are now organized below each other to make automatic code
generation easier.
- Since we needed to touch this code anyway, I also fixed Xmp.dc.creator
and Xmp.iptcExt.ModelAge to be multiline. This closes#7286.
- The old icons used for the date button, add, and remove row buttons
were replaced by gimp-grid, list-add and list-remove.
Since this was the last .ui file used in GIMP plug-ins, we remove all
files from the .ui subdirectory and references to that.
Note that there are several more places where GtkBuilder is used, but
those cases uses strings defined in code instead of .ui files.
We had a lot of duplicate code using gexiv2_metadata_try_set_tag_string
and then checking for errors.
Simplify this by re-using the existing set_tag_string function by
introducing an extra parameter that tells us whether or not to clear
the tag first.
It was a temporary code added before relevant code landed in babl. The necessary merge request landed in Babl some time ago, and Gimp now requires Babl version 0.1.98, which includes the needed commit.
Related to merge_requests/509
In the master branch we depend on gexiv2 0.14, so we can remove the
deprecated functions and replace them with the "try_" versions.
We can't backport this, since our stable branch has a lower dependency
for gexiv2.
This ports the Import and export dialogs to use GimpProcedureConfig.
It covers all properties except GUI-only options
(which were still ported to libgimpui rather than direct GTK calls)
Additionally, a warning was fixed and mnemonics were added to the
property titles.
The metadata-viewer uses a GtkBuilder .ui file to create the interface.
In GIMP we prefer our interfaces to be created in code and these builder
files are also not available anymore in GTK4.
This commit removes the .ui file and support code, and creates the
interface from code in our plug-in.
In 2.10, print_temp_proc_name () took in the image id. When it was
updated to take in GimpImage, it still assumed the g_strdup_printf
parameter was an integer.
This is fixed by calling `gimp_image_get_id ()` on the image parameter.
While testing the DCX import MR I saw that one image (abaddon.dcx) was not
recognized. This image uses 4 planes with 8 bpp while we only support
3 planes. The 4 planes type includes an alpha channel.
A few small changes allow us to also load 4 planes by allowing 3 or 4
planes instead of only 3.
This allows file-psd-load-metadata to show a warning message like the
PSD plug-in does when unsupported features are loaded.
As PSD metadata does not store rasterized versions of fill layers,
a new option is added to show these layers are dropped entirely unlike
with PSDs.
The dialog title changes based on which plug-in called it.
This adds the PSD metadata plug-in procedure call to the JPEG
plug-in, as part of implementing issue #7549.
Also implements the import half of issue #1842.
JPEGs only store image-level metadata like paths.
This adds the PSD metadata plug-in procedure call to the TIFF
plug-ins, as part of implementing issue #7549.
Also implements the import part of issue #2921.
TIFFs can have both image and layer-level metadata.
The load_paths() function was removed, as the PSD plug-in should
handle this now.
Creates a new public procedure that can be used by JPEG/TIFF files to
load any PSD-formatted metadata they have. This consolidates code
to the PSD plug-in, and lets JPEG/TIFF get immediate updates as the
PSD plug-in improves its own metadata support.
Note that only Macintosh formatted metadata is currently supported
by the PSD plug-in; IBM PC formatted metadata is reversed and not
yet interpreted.
Some valid PCX/DCX files wouldn't load because the bytes per line
header check can be off by one due to integer division rounding.
This adds 1 to the equation to account for this.
DCX files are containers that store up to 1023 PCX files.
The PCX plug-in is rearranged to allow reading multiple PCX images per
file, rather than assuming there's only one image.
After testing a bit more, I realized that the thread was constantly re-rendering
the thumbnails, even though I didn't touch the "white-background"
button/argument.
This was not just a completely invisible problem, it actually affected the page
selection (it was very hard to select pages by clicking on them, it was randomly
working, and more often not selecting anything). This is how I realized there
was a problem.
The reason was simply that I was never actually calling g_cond_wait() because of
a first_loop flag I forgot to set.
Note that docs of g_cond_wait() explains that it is possible that "spurious
wakeup" happen. At first I thought I had this issue, which is why this commit
also adds a boolean flag to check after a wakeup, to make sure that I was in the
"condition met" case and not the "spurious wakeup" one.
Even though I realized afterwards the real reason was much more stupid, I still
left this additional check.
Fortunately this issue doesn't seem to affect the 2.10 code. Or to be more
accurate: the continuous render very likely happens there too, yet it doesn't
break page selection interaction with GTK+2 as far as I can see.
Port commit 41f40f530a from gimp-2-10 branch to the main branch:
While at first, the idea of always loading PDF with transparency seemed good
(commit 7aff7e9c70), I realized that a lot of administrative PDF (generated with
text and vector graphics, rather than scans or alike containing raster) actually
have transparency. So now all these documents load with transparent background.
Clearly all the office software are assuming that PDF readers will fill the
background with white.
So add a checkbox to decide whether or not to fill the image with white. I don't
update the PDB procedure. I'll just do this on the main dev branch (while also
updating a bit the code to newer API).
Fortunately I regularly open such PDF documents with GIMP and could witness this
no-transparency expectation before we released GIMP 2.10.34! 😅
As side changes, I also:
* ported file-pdf-load to work with GimpProcedureConfig arguments instead of
GimpValueArray;
* ported the dialog to GimpProcedureDialog and generating as much of it as
possible (except for the page selector/preview, and resolution entries);
* renamed the "pdf-password" argument to "password";
* added the "target", "antialias" and "white-background" procedure arguments.
A few issues which would deserve to be looked at more closely in the future:
* adding "width" and "height" arguments and decide how to handle "resolution";
this will likely be better handled with a new GimpVectorLoadProcedure subclass
to support vector formats in particular;
* shouldn't page selection be handled in a better way? Probably this could be
handled by adding a generic logic in GimpLoadProcedure (as multi-page support
is a common feature across image formats);
* GimpInt32Array arguments ("pages") can't be stored anyway right now.
* the "target" arg should be an enum.
This is a placeholder which is not meant to appear in the menu. Our new system
uses placeholders internally, but plug-ins cannot make use of these.
Not sure anyway if this is so useful in the cases of plug-ins. At least, I don't
feel it is for these particular use cases.
I noticed after porting the last few plug-ins that GimpPreview went
to black when you unchecked the auto-preview option.
These widgets must be added directly to the dialogue rather than via the
new API in order for the unfiltered image drawable to be loaded
properly. They will eventually be removed in favor of on-canvas preview,
but let's get them working correctly for now.
Michael Natterer