Add flag GIMP_METADATA_SAVE_COLOR_PROFILE to GimpMetadataSaveFlags and
initialize it from gimp_export_color_profile() in
gimp_image_metadata_save_prepare().
Adapt all plug-ins to use the bit from the suggested export flags and
pass the actually used value back to
gimp_image_metadata_save_finish().
This changes no behavior at all but creates hooks on the libgimp side
that are called with the context of an image before and after the
actual export, which might become useful later. Also, consistency
is good even though the color profile is not strictly "metadata".
(cherry picked from commit c667fdc5c0)
...export dialogs
Move most stuff out of the "Advanced" expander, only nerdish encoding
options are left there.
Issue #701: Add a "Save color profile" toggle which honors the default
value configured in preferences and always saves the profile when
enabled.
(cherry picked from commit 540cfa9611)
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.
(cherry picked from commit 870ca6334d)
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.
Load as much of a broken/truncated JPEG as possible:
As soon as loading the scanlines has started, set a new setjmp()
location that doesn't abort loading alltogether but keeps the loaded
part of the image.
...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().
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.
Set use_orig_quality when both the quality and the subsampling are the
same as in the originally-imported jpeg.
Also improve subsampling initial selection: use the original subsampling
unless the default one is the best or the original one is the worst.
The current code was wrong and would often use the default subsampling
even when worse than the original one.
Rather than just discovering them by chance, a simple grep and some
search and replace are much more efficient! :-)
Cleaning only done on C and automake files.
it used to be a typedef to gpointer and actually was a cmsHPROFILE.
Change its API to be more "standard", remove the public close()
function. The object caches both the cmsHPROFILE and the data/length
ICC blob, so conversions between the two become obsolete (simply call
get_lcms_profile() or get_icc_profile()).
Adapt everything to the new API, but port it in a naive way for now,
the code doesn't take advantage of the new possibilities yet (like
refcounting).
gimp_color_config_get_foo_profile() -> get_foo_color_profile()
because the old names clash with possible future accessors for the raw
filename properties.
Return flags based on what metadata is actually present in the image.
Returning of a suggested value for GIMP_METADATA_SAVE_THUMBNAIL needs
support from gimp_image_metadata_load_prepare() and is still missing.
Port all plug-ins to use the new API, the suggested values are however
overridden by parasites and whatever special code was devised for the
individual plug-ins. This needs to be fixed.
Arithmetic coding is a feature of the JPEG standard. Although libjpeg
had always implemented arithmetic coding, it was compiled out by default
due to patents.
Those patents have now expired.
libjpeg 8 now enables arithmetic coding by default. Distributions which
use libjpeg < 8 can also support arithmetic coding by using the
appropriate CFLAGS to enable it. libjpeg-turbo 1.3.1 also has support
for arithmetic coding and is in popular shipping distributions.
Software such as jpegtran can losslessly convert Huffman compressed
images to arithmetic coding and vice versa. The lossy behavior of JPEG
does not happen at this (bit coding) layer of the format.
This initial patch provides a checkbox (disabled by default) to create
files which use arithmetic coding. It also has a tooltip warning that
such files may not be compatible with older decoders.
and clean up the formatting of the call and the lines around it. Now
we can check the various (disabled) export options for regressions
again by changing a single line in gimp_export_image().
