...always AdobeRGB!
Change all file plug-ins to never call gimp_image_metadata_load_finish()
with the GIMP_METADATA_LOAD_COLORSPACE when they loaded a color profile.
This keeps gimp_image_metadata_load_finish() from assigning a profile
from DCT even if the loaded profile was GIMP's built-in sRGB.
Similarly to other export dialogs, we don't consider anymore metadata or
profile writing as being advanced options. Since these were the only
options shown in our current WebP export dialog, I removed the expander
altogether and moved everything out.
See also commit 540cfa9611.
Profile and output linearity decision was doubled as save_layer() and
save_animation() and I realize that I forgot to update the
save_animation() one in earlier commits.
To avoid code copy-paste and divergence, I added an internal
webp_decide_output() function which I use in both aforementionned calls.
Same as other formats, we make sure that an explicitly set profile TRC
is always followed. When no profile is set, we always export as sRGB
when there is precision downsizing to avoid shadow posterization, since
WebP stores 8-bit max per channel (as far as I know, or at least as far
as we implemented it in our plug-in).
We only take the storage format into account when it is 8-bit linear
with profile export. In such case, we avoid conversion from 8-bit linear
to 8-bit sRGB.
This is different to TIFF export for instance, where we fallback on
following storage format TRC as we are able to export all sort of
precisions, hence with minimum quality loss.
... produces incorrect result.
Similar to previous fixes to JPEG and PNG exporters. Here WebP always
export 8-bit per channel colors, so let's always keep it non-linear.
Simply when the original data was linear, if we save the profile,
convert it to sRGB before exporting.
In an animated WebP, chances that layers/frame have the same size is
high. It is uneeded to free then malloc again a buffer at each frame,
unless we need more allocated memory.
This is probably not so significant, but still feels nicer.
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
Various plug-ins exporting metadata should now follow preferences, which
would override any default. Of course these preferences can still be
overriden by saved settings (global parasite), previous run settings,
and finally through the GUI when interactive.
This is a privacy concern. Whereas importing metadata is usually a good
idea, exporting it should be a conscious action. A lot of private data
can be leaked through metadata and many people don't realize it (which
also usually means they don't need it). On the other hand, the people
who realize it are the ones who would explicitly edit the metadata and
check what they want to be exported or not.
This is only a first step. Some people may want to always export the
metadata and for these people, there should be abilities to change the
default.
fopen() modes "wb+" and "w+b" are aliases of the same opening mode
(truncate/create in binary read/write). But it turns out that Windows
implementation does not understand "wb+". The alias "w+b" works fine in
my tests.
... failed.
See bug 791514. It seems that the file opening fails for webp exporting,
but the error string is not informative enough.
As a general rule, we should have as informative errors as possible.
...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().
The hint text was shown on kmax change, but not when it was 0 or 1 from
start (i.e. when previous export was 0/1 so these were the saved
values). Run the callback upon construction to initialize properly this
hint label.
Since libwebp 0.6, the keyframe max distance (kmax) has been changed,
and in particular all special cases are now handled by kmax (it used to
be weird cases of kmin and kmax intertwined with no logics, for instance
kmax == 0 AND kmin > 0 would mean all frames are keyframes).
Now it is much more logical, and kmax == 0 means no keyframes, whereas
kmax == 1 means all frames are keyframes. See also:
2dc0bdcaee
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
webp-save: Add UI elements for 'minimize size' toggle, and a dependent
'max key-frame distance' setting.
* If 'minimize size' is active, max-kf is disabled (which is equivalent to
setting it to infinity). Key-frame cost file size, that's why.
* If 'minimize size' is disabled, you get to choose how far key-frames
(=cue points) will be inserted at max.
- WebPPictureImportRGB(A)() docs say these functions return "false in
case of memory error". Handle such cases.
- status was not updated when WebPEncode() would fail in save_layer().
- gegl_buffer_flush() is unnecessary just before last unref-ing GEGL
buffers. This is done automatically at destruction.
- Destroy resources at the same level as they were created if possible.
This makes the code more readable and maintainable. Consequently
better not unref parameter GEGL buffers inside combine_buffers().
- Some minor formatting cleanup.
The "Preset" feature changes encoding parameters not exposed in our GUI.
Thus it looks like the option is broken as whatever you select, nothing
is updated in the export dialog.
This is also inconsistent with what we call presets in the rest of GIMP:
they are used to save and load values for all fields as a dynamic and
editable list (whereas here that's a pre-defined list in libwebp setting
only a subset of options).
`cwebp` manual defines "preset" as: "Specify a set of pre-defined
parameters to suit a particular type of source material."
Thus call the field "Source type" and add a tooltip "WebP encoder preset"
so that people don't expect a way to save settings whereas the ones used
to the WebP encoder parameters still find their way.
...in the export dialog
- change the *preset field to a proper enum
- clean-up some code related to preset
- change the UI dialogs to use a GimpIntComboBox
- misc style fixes
- quite modified by mitch to be much less code
- get_preset_from_id() was defined in file-webp-dialog.c but used in
file-webp.c only. Move it there.
- Make the preset list available in file-webp-save.h header (since it
is specifically an encoder attribute) as static, because it is used
both in the dialog ("preset" choice list) and the main file (for match
of the "preset" parameter as internal ID to a WebPPreset when run as
non-interactive).
- Generate the "preset" parameter description from the preset list.
This way, even if this list were to change (in some hypothetical
future), the description (and in particular the list of possible
values and their int match) won't end up wrong.
- "enum WebPPreset" is typedef-ed to "WebPPreset".
- Use G_N_ELEMENTS to compute length of arrays on the stack (equivalent
to the current code but shorter and simpler to read).
- Many formatting fixes.
- change the *preset field to a proper enum
- clean-up some code related to preset
- change the UI dialogs to use a GimpIntComboBox.
- misc style fixes
...in the export dialog
Read back timestamps into layer names. Adds the exact duration to the
layer names. Previously, they were not reloaded correctly.
- Default parameters must be set before gimp_get_data(). Otherwise
when you export the first time, you end up with broken defaults
(basically everything to 0, in particular a problem with quality
values of 0 which makes an export failure).
- Some minor formatting here and there and an unused variable.
animated webp saving: parse time-stamp from layer_name (instead of using
default value of '100')
also:
- add a default delay field to UI, in case time-stamps are not present.
- add a 'force delay' checkbox
- revamp the whole UI to look like the GIF saving UI.
WebP saving: various improvements in file-webp-save.c
- reorganizes the main loop
- fixes (temporarily) the bad timestamp by using fixed 100ms delay between frames
- fixes the progress bar
- takes care of resource clean-up for some previously unchecked error paths
- uses 'minimize_size' and 'allow_mixed' options more appropriately
- only remuxes the final bytestream when ICC profile is present. For
most common case, we insert the loop-count information during muxer
creation instead of by remuxing at the end.
- handle all sorts of image types, gegl_buffer_get() will convert to u8
- specify GIMP_EXPORT_CAN_HANDLE_LAYERS_AS_ANIMATION
- modify the export duplicate, not the original image
- fix handling of the drawable type and only save "R'G'B'A u8"
or "R'G'B' u8", fixes bug 770664.
- completely redo run(SAVE_PROC) to deal with export correctly
- turn global variables into the standard SAVE_PROC, PLUG_IN_BINARY etc
defines
- simplify the save dialog
Jehan