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.
Some libpng errors can safely be marked as nonfatal, which is much
better than simply failing in those cases.
Thanks to John Bowler for pointing out this solution.
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().
start with flags = ALL (which now includes all possible current and
future flags), and optionally *remove* individual flags instead of
adding them. This way the plug-ins default to TRUE for future flags.
So the plug-in has the chance to decide whether it wants to trust the
metadata information (e.g. resolution). Also reorder parameters in
gimp_image_metadata_save_finish(). Change all plug-ins accordingly.
Based on original patches from Hartmut Kuhse and modified
by Michael Natterer. Changes include:
- remove libexif dependency and add a hard dependency on gexiv2
- typedef GExiv2Metadata to GimpMetadata to avoid having to
include gexiv2 globally
- add basic GimpMetadata handling functions to libgimpbase
- add image and image file specific metadata functions to libgimp,
including the exif orientation image rotate dialog
- port plug-ins to use the new APIs
- port file-tiff-save's UI to GtkBuilder
- add new plug-in "metadata" to view the image's metadata
- keep metadata around as GimpImage member in the core
- update the image's metadata on image size, resolution and precision
changes
- obsolete the old metadata parasites
- migrate the old parasites to new GimpMetadata object on XCF load
The new by-row iteration doesn't re-write the length
value for each row. In general it is not safe to modify
the iterator data because the internal logic depends
on the public data, but this specific case is new.
Currently PNG "comment" is saved in iTXt (UTF-8) if supported, tEXt
(ISO-8859-1) otherwise. The problem is that some software out there like
ImageMagick would apparently only read tEXt comments.
Therefore the replacing algorithm is:
1/ if we would not lose any character in a conversion from UTF-8 to
ISO-8859-1, we save in tEXt, whether or not the platform supports iTXt.
2/ if we would lose comment data in the conversion while iTXt is
supported, we save in iTXt.
3/ if iTXt is not supported, we save in tEXt anyway and discard any
non-convertible character, unless the finale result is an empty string
(in which case, we don't save any comment).
- Add new enum GimpComponentType which contains u8, u16, u32 etc.
- Change GimpPrecision to be u8-linear, u8-gamma, u16-linear etc.
- Add all the needed formats to gimp-babl.c
- Bump the XCF version to 5 and make sure version 4 with the old
GimpPrecision enum values is loaded correctly
This change blows up the precision enums in "New Image" and
Image->Precision so we can test all this stuff. It is undecided what
format will be user-visible options in 2.10.
iCCP profile was changed from png_charpp to png_bytepp in 1.5.x (cf.
libpng manual). Older versions of libpng still works of course, but
we fix warnings for recent versions.
with no text chunk, in that case 'i' == tile_height and
*** glibc detected *** ...2.0/plug-ins/file-png:
double free or corruption (out): 0x00000000011af590 ***
Doesn't work yet for 16bit PNGs, there is a weird crash in libgimp
but I didn't do anything...
This closely follows the old pixel region based code, which might
be suboptimal for gegl, but has the advantage of keeping metadata intact.
Indexed currently is disabled, needs resurrecting.
