- This is unneeded in all import procedures. See previous commit. Note though
that this is not because of a change in previous commit. This was already
useless previously. The file set with this PDB function was overridden by the
core anyway (i.e. even before the previous commits).
In app/file/file-import.c:file_import_image(), the imported file is correctly
set (so there is no need to set it from plug-in, which anyway libgimp's
gimp_image_set_file() was not doing) and the XCF file is reset to NULL
(rendering the call to gimp_image_set_file() in a GimpLoadProcedure useless).
- Similarly, this is a useless call in export procedures because
app/file/file-save.c:file_save() overrides such call too. I could only see one
such case for JPEG export, which was quite useless.
- Finally in other types of plug-ins, setting a non-XCF file extension was
interfering with the save feature (similarly to commit e6e73e14c7). I only
fixed the screenshot implementations doing such a thing.
- I left a few usages which will have to be looked at more in details later.
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.
Instead of having a single "Planar RGB" format in the list, let's add
this as a generic parameter. Not only does it make the feature
symmetrical to "file-raw-save", but it also bring the ability to all
multi-channel formats. So now, we can load RGB, RGBA, GRAYA, whatever
the bit depth and the data type stored in planar configuration.
… "endianness".
The list of formats being a single list was actually interesting
UI-wise, in the case where you aren't sure of the data layout (but say
you know at least the dimensions), you can easily and quickly scroll
through the combo list (e.g. with keyboard arrows).
But when you knew your data, it was a pain to use. And as a general
rule, so many choices in a list is not the best interface.
I broke the option into 3 options, and in particular adding a
"data-type" which would tell what type of values are stored (integer,
signed or unsigned, or float) and an "endianness" to tell the byte
order. The idea behind is that these don't change the layout of
components and their size. It means that we can still do the
scrolling-randomly-through-formats trick in some fashion because we
might likely be able to detect shapes when we get at the right layout,
even though we are still set to use the wrong data type and/or the wrong
endianness.
… loading support as raw data.
Barely any new code (and actually a bit chunk of removed code) as we are
using generic code paths now.
"file-raw-load" procedure now supports all possible formats which can be
exported by the "file-raw-save" procedure (and more).
Only thing remaining now is looking how to simplify the GUI because this
overlong Pixel format combo box is quite a pain.
Since we can now export these, let's add import support.
I copied the function halfp2singles() from babl code (as-is, without
formatting according to our coding style on purpose as we might just
want to switch this again later on).
I add the Little and Big Endian variants, but not the signed one for
now, because I am unsure how common it is. We have signed grayscale
variants, but it might be specific use cases there.
While adding these new loading support, I factorize the code when
possible by making all full-bytes RGB/Grayscale code more generic and
using the same code paths. In particular, raw_load_gray_8_plus() is now
removed as raw_load_standard() will handle all full-bytes use cases
where the input and output formats have the same components in same
order.
Also RAW_RGB and RAW_RGBA are renamed to RAW_RGB_8BPP and RAW_RGBA_8BPP
respectively.
- rename raw_load_gray16() into raw_load_gray_8_plus() and make it
handle all full-byte grayscale data. Move 8-bit grayscale data to use
this function as well.
- As a consequence of the previous point, we can also easily support
32-bit grayscale images (little/big endian, signed/unsigned).
- Make preview image code more generic as well.
Also I improve a bit code from previous commit in raw_load_rgb565(). The
allocated and read code didn't need to be the size of the full line
stride. Just the tile rectangle width was enough.
Rather than allocating 2 huge data buffers of the whole image size (one
in RGB565 and one in RGB-u8), just iterate through the file only
creating one single small temporary data buffer for single input line in
tiles returned by the iterator. This will be much better,
memory-efficiency wise.
Should have paid more attention. I left 2 warnings in the file:
> plug-ins/common/file-raw-data.c:1949:22: warning: variable ‘procedure’ set but not used [-Wunused-but-set-variable]
> plug-ins/common/file-raw-data.c:1970:48: warning: ‘bpp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Even though the scale entries have maximum values based on the file
size, it's still too big for many formats (multi-byte ones) when
thinking in terms of pixels.
Moreover if growing the offset or any dimension, comes a point where the
other dimension needs to shrink. So let's compute max pixels and update
other values depending on this.
Note that it's still quite easy to crash the dialog with big dimensions,
triggering X Window System errors about unsufficient resources in
GimpPreviewArea code. This will have to be handled accordingly.
- Add various relevant arguments to "file-raw-load" PDB call: width,
height, offset, color-representation, palette-offset palette-type and
palette-file. This will make the procedure actually usable for
scripts.
- Use procedure config so that we get configuration storage as all other
ported plug-ins.
- Update the source to use passed-in config object with these new
arguments rather than global variables.
- The load dialog now uses the GimpProcedureDialog which means a lot
simpler and nicer to read/debug code (we don't need all the code for
argument syncing).
- "file-hgt-load" code now uses a HgtSampleSpacing enum, which makes
code nicer to read, with semantic constant names.
- Do not show the dialog anymore for HGT load when sample spacing
detection worked correctly. Indeed, offset and profile selection were
making sense for random raw data, not for HGT file which we know how
to process.
- Improve detection logic for sample spacing: in interactive mode, we
always try and detect and show the dialog when spacing detection
failed; in non-interactive mode, we only detect when "sample-spacing"
argument is explicitly set to HGT_SRTM_AUTO_DETECT.
- The argument "image-type" of "file-raw-save" PDB call is renamed to
"planar-configuration" to sync with the natural language label. Also
it now uses a separate RawPlanarConfiguration enum rather than using
specific values of the RawType enum (which made that the possible
values were 0 or 6, which was a weird API in GIMP 2.10).
The plug-in still cannot load all possibly exportable formats (after
commit 01e0675f67) and I'm still wondering about whether
"color-representation" argument in the load call should not be broken
down into several arguments (it has both advantages and disadvantages).
This will be handled in further commits. For this first step, I needed
to clean the load code.
Another part for the fix: now that it is possible to export any of the
color model and bit depth supported by GIMP core, we should make the
dialog settings clearer. In particular, don't just always show "RGB"
structure sample.
If an alpha channel is present, also show RGBA samples, and if it's a
grayscale image, show "Y" or "YA" samples. Actually when it's a
non-alpha grayscale, just make the option insensitive as planar and
contiguous will be the same thing.
Only port the export dialog so far. We'll see later for the load dialog.
This uses the new gimp_procedure_dialog_get_int_radio().
While doing this, I also better name "Image type" to "Planar
configuration", which is how DICOM standard and TIFF call the same
option. Within this settings, "Standard" is renamed "Contiguous" as a
more correct naming than a very vague "standard".
Similarly I rename "Palette type" to "Palette's configuration".
This is a first step to make RAW export clearer in the path of fixing
issue #7091.
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.
when Offset and Dimensions Bigger than File Size.
If we didn't read the exact amount of bytes, the whole image would be
filled with white.
Let's change this, so we read as much bytes as we can, and fill the rest
with white.
I had completely forgotten about Coverity Scan but today received an
email with some new scan results. This was one of the warnings that we
had a possible resource leak.
In truth, this is mostly a false positive since gimp_export_image() will
flatten the image. Yet why not be thorough…
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.
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.
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).
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.
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.
All babl formats now have a space equivalent to a color profile,
determining the format's primaries and TRCs. This commit makes GIMP
aware of this.
libgimp:
- enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA
as deprecated aliases, add PERCEPTUAL values so we now have LINEAR,
NON_LINEAR and PERCPTUAL for each encoding, matching the babl
encoding variants RGB, R'G'B' and R~G~B~.
- gimp_color_transform_can_gegl_copy() now returns TRUE if both
profiles can return a babl space, increasing the amount of fast babl
color conversions significantly.
- TODO: no solution yet for getting libgimp drawable proxy buffers in
the right format with space.
plug-ins:
- follow the GimpPrecision change.
- TODO: everything else unchanged and partly broken or sub-optimal,
like setting a new image's color profile too late.
app:
- add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as
replacement for all "linear" booleans.
- change gimp-babl functions to take babl spaces and GimpTRCType
parameters and support all sorts of new perceptual ~ formats.
- a lot of places changed in the early days of goat invasion didn't
take advantage of gimp-babl utility functions and constructed
formats manually. They all needed revisiting and many now use much
simpler code calling gimp-babl API.
- change gimp_babl_format_get_color_profile() to really extract a
newly allocated color profile from the format, and add
gimp_babl_get_builtin_color_profile() which does the same as
gimp_babl_format_get_color_profile() did before. Visited all callers
to decide whether they are looking for the format's actual profile,
or for one of the builtin profiles, simplifying code that only needs
builtin profiles.
- drawables have a new get_space_api(), get_linear() is now get_trc().
- images now have a "layer space" and an API to get it,
gimp_image_get_layer_format() returns formats in that space.
- an image's layer space is created from the image's color profile,
change gimpimage-color-profile to deal with that correctly
- change many babl_format() calls to babl_format_with_space() and take
the space from passed formats or drawables
- add function gimp_layer_fix_format_space() which replaces the
layer's buffer with one that has the image's layer format, but
doesn't change pixel values
- use gimp_layer_fix_format_space() to make sure layers loaded from
XCF and created by plug-ins have the right space when added to the
image, because it's impossible to always assign the right space upon
layer creation
- "assign color profile" and "discard color profile" now require use
of gimp_layer_fix_format_space() too because the profile is now
embedded in all formats via the space. Add
gimp_image_assign_color_profile() which does all that and call it
instead of a simple gimp_image_set_color_profile(), also from the
PDB set-color-profile functions, which are essentially "assign" and
"discard" calls.
- generally, make sure a new image's color profile is set before
adding layers to it, gimp_image_set_color_profile() is more than
before considered know-what-you-are-doing API.
- take special precaution in all places that call
gimp_drawable_convert_type(), we now must pass a new_profile from
all callers that convert layers within the same image (such as
image_convert_type, image_convert_precision), because the layer's
new space can't be determined from the image's layer format during
the call.
- change all "linear" properties to "trc", in all config objects like
for levels and curves, in the histogram, in the widgets. This results
in some GUI that now has three choices instead of two.
TODO: we might want to reduce that back to two later.
- keep "linear" boolean properties around as compat if needed for file
pasring, but always convert the parsed parsed boolean to
GimpTRCType.
- TODO: the image's "enable color management" switch is currently
broken, will fix that in another commit.
Since SRTM-1 and SRTM-3 data have a fixed image size, it is actually
very easy to auto-detect these by checking the file size. There is no
need to ask the user to select between the 2 variants (even though these
values are made quite obvious by official download links).
I still left the dropdown appear optionally if the detection fails for
some reason (we never know, at least that makes a fallback, for instance
to be able to load partial data!). Yet now by default, HGT file settings
should be fully auto-detected.
g_set_error() so that when samplespacing is not a valid argument for
file-hgt-load, the error is properly propagated.
Also add a g_warning() to get the error in the terminal as well.
This allows for it to show as a separate item in the open dialog, with
proper naming. Also add proper arguments so that the handler works as a
PDB function in non-interactive mode, unlike file-raw-load which works
only interactively.
- Display title "Digital Elevation Model data" instead of just "Image".
- Don't show the type combo anymore, since HGT is always 16-bit signed
integer in big endian.
- Don't show the width and height either, but instead show a dropdown
list to choose between either SRTM-1 or SRTM-3 data. There seems to be
only these 2 types of data, and this will determine the width and
height. This choice (SRTM-1 vs 3) will mostly likely be better known
by people than knowing what image dimension they have to set,
especially since official links for such files seem to all include the
information.
- Add some parentheses to sizeof (*pointer). Maybe it's just me, but it
is just a bit clearer to me.
- Free in_raw when out_raw allocation failed.
- Use strrchr() instead of strchr() to get the extension (I had a case
when testing where the file was inside a folder named similarly with a
".hgt" and it would break the comparison test).
- Do a case-insensitive comparison. Even though the original files from
NASA use lowercase, just to be sure.
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
