The layer blend space, composite space, and composite mode
properties have a special AUTO value, which may map to different
concrete values based on the layer mode. Make sure we can change
this mapping in the future, without affecting existing XCFs (saved
after this commit), by encoding these properties as follows:
When saving an XCF, if the property has a concrete (non-AUTO)
value, which is always positive, encode it as is. If the property
is AUTO, which is always 0, encode it as the negative of the value
it actually maps to at the time of saving (note that in some cases
AUTO may map to AUTO, in which case it's encoded as 0).
When loading an XCF, if the encoded property (stored in the file)
is nonnegative, use it as is. Otherwise, compare the negative of
the encoded property to the value AUTO maps to at the time of
loading. If the values are equal, set the property to AUTO;
otherwise, use the concrete value (i.e., the negative of the value
stored in the XCF).
Note that XCFs saved prior to this commit still load fine, it's
simply that if we change the AUTO mapping in the future, all their
AUTO properties will keep being loaded as AUTO, even if the
resulting concrete values will have changed.
We were still saving channel colors in 8 bit, this additionally
saves/loads the color as float values. Still save the old PROP_COLOR
for compatibility.
Both in the GimpImage API and in the GUI. The toggle in the save
dialog now controls ZLIB compression directly. Changed the various
info labels accordingly. Ditch the XCF parasite that saved the XCF
compat mode.
Enable 64 bit file offsets in XCF files, starting with newly added XCF
version 11.
We use at least version 11 if:
- we would use the previous version 10 (essentially skipping 10)
- the in-memory size of the image is larger than 4 Gig
Change the xcf_read_foo() functions to take the XcfInfo* instead of
a GInputStream*, and make them advance the info->cp offset by
themselves. Makes xcf-load.c a lot more readable.
Step one, without changing anything in the saved XCFs yet:
Abstract reading and writing of file offsets away into their own
xcf_read_offset() and xcf_write_offset() functions, which take
"goffset" instead of "guint32". Also change xcf_seek_pos() to take a
goffset argument.
Change all file offset variables in xcf-load.c, xcf-write.c and struct
XcfInfo to goffset, and add new member "bytes_per_offset" to XcfInfo,
which is currently always 4.
Largely based on a patch by Ell, with the enum type renamed and
various small changes. Adds another axis of configurability to the
existing layer mode madness, and is WIP too.
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.
which can be used to load/save XCF from/to arbitrars streams. Use the
new functions from the load/save procedure invokers.
This commit also fixes a leaked open file ans input stream for each
loaded XCF.
...XCF channel and layer properties
The properties PROP_ACTIVE_LAYER, PROP_FLOATING_SELECTION,
PROP_ACTIVE_CHANNEL saves the current object pointer the @info
structure. Others like PROP_SELECTION (for channel) and
PROP_GROUP_ITEM (for layer) will delete the current object and create
a new object, leaving the pointers in @info invalid (dangling).
Therefore, if a property from the first type will come before the
second, the result will be an UaF in the last lines of xcf_load_image
(when it actually using the pointers from @info).
I wasn't able to exploit this bug because that
g_object_instance->c_class gets cleared by the last g_object_unref and
GIMP_IS_{LAYER,CHANNEL} detects that and return FALSE.
Don't skip the first 10 bytes. That code was there to skip the magic
"GIMP_XMP_1" of the old "gimp-metadata" parasite. Instead, properly
check for that magic in xcf_load_image() and pass only the actual XMP
to gimp_metadata_set_from_xmp(). Also remove the +10 hack in file-exr.
With gimp_guide_custom_new(), you can create a custom guide with a different
style on canvas (other pattern/color/width). A custom guide won't be saved
and could be used, for instance, for specific GEGL op guiding.
Add new XCF property FLOAT_OPACITY and always save both the old 8-bit
and the new float opacity of layers and channels. Float opacity is
saved after the 8-bit one so when loading, it overwrites the limited
8-bit value with the proper precision. Do not increase the XCF version
number because old GIMP versions will simply skip the unknown
FLOAT_OPACITY and keep using the 8-bit value.
- gimp-image-set-filename PDB wrapper: implement the same there in
a few lines
- xcf-load.c: use gimp_image_set_file() instead, and get rid of the
last use of filename in xcf/ in favor of GFile
The possible failure of `g_file_replace()` was overlooked, as well as
the error which may have been created and could be useful information
for the developers.
The "filename" parameter must be in UTF-8 and in URI format (for
instance file://path for local files, and not just a path).
Cf. `g_file_new_for_uri()` documentation:
@uri: a UTF-8 string containing a URI
GIMP's OVERLAY mode was identical to SOFTLIGHT. This commit fixes the
issue and introduces a NEW_OVERLAY mode and enum value.
- change gimp:overlay-mode to be a real (svg-ish) overlay mode
- when compositing, map OVERLAY to gimp:softlight-mode
- when compisiting, map NEW_OVERLAY to gimp:overlay-mode
- bump the XCF version when NEW_OVERLAY is used
- map OVERLAY to SOFTLIGHT when loading and saving XCF
- map OVERLAY to softlight in all PDB setters
- map OVERLAY to softlight when deserializing a GimpContext
- change all paint mode menus to show an entry for NEW_OVERLAY
instead of OVERLAY
- change PSP, PSD and OpenRaster to use NEW_OVERLAY
These changes should (redundantly) make sure that no OVERLAY enum
value is used in the core any longer because it gets mapped to
SOFTLIGHT at all entry points, with the downside of introducing a
setter/getter asymmetry when OVERLAY was set in a PDB api.
Get rid of most seeking by writing the tile offsets to a table in
memory, instead of directly to the file after each tile. Only seek
back after writing all tiles, in order to save the entire table at
once.
- add gimp_image_get,get_xcf_compat_mode()
- add a compat toggle to GimpFileDialog which is shown and sensitive
only for a save (not export), and if the image structure allows
to save an old version at all. The button also has a tooltip
which explains why it is sensitive and what it does
- add "gboolean xcf_compat" to file_save_dialog_save_image()
- in file_save_dialog_save_image(), call image_set_xcf_compat_mode(TRUE)
only around the call to file_save() and set it to FALSE after saving
- in xcf_save_invoker(), honor the image's XCF compat flag and save an
RLE-compressed XCF if possible
The above is very convoluted and doesn't pass the "xcf_compat" boolean
directly because we can't change the parameters of gimp-xcf-save, and
because the gimp-xcf-save might be called indirectly.
Change XCF saving to never seek past the end of the partially written
file. The only places where we still did this was when skipping the
offset tables for layers, channels, levels and tiles.
Now we write an all-zero offset table first, and then only seek around
in areas of the file that already exist. This also simplifies the code
a bit. Changed comments to make it clear what happens.
Ell