...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.
by using gimp_image_get_effective_color_profile() instead of just
_get_color_profile(). Don't look at the preference setting because PSD
should behave more like "save" than "export" and save everything.
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.
... depending on UI language
Use gimp_register_file_handler_priority(), added in the previous
commit, to increase the priority of the merged PSD loader, so that
the non-merged loader is always preferred over it (unless
explicitly chosen), regardless of the UI language.
PSD files may include a "merged", pre-composited, version of the
image (in Photoshop, this is the case when saving files with
"Maximize Compatibility" enabled; GIMP always saves the merged
image data in exported PSD files.) This commit adds support for
loading the merged image version from PSDs, instead of the full
layer hierarchy. This is useful when loading PSD files that use
features that we don't currently support, and therefore can't
render correctly, such as adjustment layers.
When loading the merged image version, we avoid loading certain
additional data from the file, such as channels, paths, and
guides, while still loading metadata, making this akin to loading
other "flat" image formats.
This option is currently exposed as an additional file type
("Photoshop image (merged)"), which has to be explicitly selected
from the file-type list when opening the image.
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.
In the file-psd plug-in, ignore the 'irrelevant' flag of layers
when loading PSD files; in particular, don't hide such layers
unconditionally. The 'irrelevant' flag seems to indicate that the
layer's content can be entirely derived without using the layer's
pixel data, and not that the layer itself it irrelevant.
Our composite modes don't correspond directly to the Porter-Duff
operators after which they're named, and these names aren't too
descriptive anyway.
Rename the composite modes as follows:
Source Over => Union
Source Atop => Clip to Backdrop
Destination Atop => Clip to Layer
Source In => Intersection
Update relevant code, including UI text, enumerator names, function
names, and action names.
When loading PSDs, insert layers to the image as the last step of
layer creation, after writing the pixel data to their buffers, so
that the data of child layers is available when their parent
group's projection is subseqeuently invalidated; otherwise, we'd
need an additional gimp_drawable_update() call after writing the
data to the buffers.
Photoshop CS5 adds support for layer groups whose nesting depth is
above 5. The end markers of these groups use an undocumented
"lsdk" key for their section dividers, rather than the usual
"lsct". This caused the PSD plugin to treat them as regular
layers, resulting in wrong layer-tree structure.
Add support for "lsdk" section dividers upon loading, and also
generate "lsdk" section dividers upon saving sufficiently-deep
groups.
When loading a PSD, set the active layer after adding all the
layers to the image, instead of at the time of its creation, since
the active layer may change when adding subsequent layers.
Tweak the layer group saving code so that the saved PSDs match
Photoshop-produced PSDs a bit more closely. For the most part, it
doesn't seem to matter much, but it does somewhat improve
compatibility with other programs that read PSDs.
And: Bug 593251 - Mask positions may be incorrect when opening a PSD
The position-relative flag of layer masks doesn't specify how the
mask position is represented in the PSD -- it's always absolute --
but rather whether the layer and the mask are linked or unlinked.
Since masks are always linked to their layers in GIMP, just ignore
this flag (and, when saving, clear the flag so that the mask is
linked to layer when loaded in PS.)
Set the layer name of group layers early on, while processing their
end marker, so that the default group name won't collide with the
names of subsequent layers, leading to wrong layer names. The real
name of the group layer is set again when processing its start
marker.
...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().
Streamline the layer-mode mapping code, to reduce duplication.
Add mappings for the following modes: Subtract, Divide, Luma/
luminance darken only (Darker Color), Luma/luminance lighten only
(Lighter Color), and Luminance (Luminosity).
Use SRC_OVER, instead of SRC_ATOP, as the composite mode for all
layers (or use AUTO, when it results in SRC_OVER), to match
Photoshop's behavior. Use RGB_PERCEPTUAL as the blend and composite
space, instead of AUTO, whose interpretation depends on the specific
layer mode, to match Photoshop's behavior for RGB images. Use NORMAL
mode, instead of NORMAL_LEGACY, with the above properties, for normal
layers, for consistency with the other layer modes, which don't (and,
indeed, can't) use the legacy modes.
The section-divider (lsct) layer resource may contain blend mode
information, which apparently overrides the blend mode specified in
the layer record. When reading such a resource, replace the layer's
blend mode with the one specified by the resource.
It seems like pass-through group layers specify normal mode in their
layer record, but pass-through in their section-divider resource, so
this commit allows correctly loading such layers.
... and get rid of the dedicated op. This gives us support for all
the blend/composite options for this mode.
Rename COLOR_ERASE to COLOR_ERASE_LEGACY, with perceptual blending/
compositing and immutable everything, and add a new COLOR_ERASE
mode, defaulting to linear blending/compositing, with mutable
everything. Modify affected code.
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.
...not divisible by 4 are incorrectly reported as corrupt
file-psd: Do not round up the extra data length field when reading
layer info.
Fixes the PSD layer extra information handling in read_layer_info() by
not rounding up the data length field to a multiple of 4.
Layers can contain extra data, which is encoded at the end of layer
records. The length of this data should always be stored rounded up to
an even byte count. When loading a PSD file, it can be expected that
this value is already rounded up and this operation should not be
necessary. If an uneven byte count is encountered, a warning is
emitted but the loading process is not aborted.
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.
... (read PSD file from PS CS3)
use a position of 0 when inserting normal layers
as they're always inserted on top of their group
-1 means inside the group when the active drawable is
a group or above it when it's not. This used to work
before layer groups or in simple cases.
Layer name source (id on 4 characters encoded in MacRoman).
psd from PS>5 have "luni" (Layer Unicode)
See https://bugzilla.gnome.org/show_bug.cgi?id=753986#c4 for more details
Janitorial on lyvr:
move IFDBG at the beginning of the function
+change the content of it
GIMP's PSD plugin was assuming that colors in PSD files are linearly interpolated
on both export and import. This commit fixes the issue by doing the following:
- when importing, assume the colors are gamma interpolated in the entire image
- when importing and exporting, treat the colors in each layer as gamma interpolated
- when importing and exporting, treat indexed colors as actually indexed colors
- when exporting, treat the interpolation in the channels and masks as linearly interpolated
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.
which share the psd.c file for query() and run(), instead of having
save's stuff commented out in psd.c, and having it duplicated in
psd-save.c for the separate binary.
Using the right Babl format (JPEG previews don't have an alpha
channel), and fixing the main scanline loading loop (which was totally
busted) make the PSD previews look like images.
...file-psd-load segfault.
Fix loading of PSDs where the number of "end group" markers doesn't
match the number of "start group" markers, which seems to be what is
saved by Photoshop in some cases/versions/whatever.
Fix the other pixel format issue in this bug: split up
get_pixel_format() into 3 functions get_layer,channel,mask_format() so
we use the right one for the right drawable type, get_layer_format()
has an "alpha" parameter that is taken from the loaded layer instead
of from the PSDimage struct.
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.
GIMP_ADD_foo_MASK -> GIMP_ADD_MASK_foo
GIMP_foo_MODE -> GIMP_BLEND_foo
GIMP_foo_CLONE -> GIMP_CLONE_foo
GIMP_foo -> GIMP_DODGE_BURN_TYPE_foo
GIMP_foo -> GIMP_TRANSFER_foo
Add compat values for the old names and compat code to script-fu
and pygimp.
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 unsaved "Working Path" was not being loaded from the PSD. Passed
this Working Path resource through the same function call as the
normal path resources, and named it "Working Path"
plug-ins/file-psd/psd-load.c: Avoid dereferencing a random pointer
on chn_a[cidx].data[i] when comp_mode is unrecognized.
Spotted by Mikael Magnusson <mikachu@gmail.com>.
I'm sure some plug-ins need to add their items *not* at the toplevel,
but since making plug-ins really tree-aware is a lot more work than
just fixing insert positions, I went for passing -1 as parent in
almost all cases. And because of laziness...
Created a resource file for plug-ins and a rule to link it to them.
The application icon file is smaller than the default one, there's no
point in doubling the size of a plug-in executable just for an icon.
If no problems turn up, this will close the bug.
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
* plug-ins/file-psd/psd-save.c
* plug-ins/file-psd/psd-util.c: Add support for reading/writing
PSDs with the Linear Dodge layer mode which is the same as GIMPs
Addition layer mode.
svn path=/trunk/; revision=27407
2008-10-22 Sven Neumann <sven@gimp.org>
Bug 556741 – Alpha layer automatically added (in psd format) but
not desired
* plug-ins/file-psd/psd-save.c: applied patch from Dennis Ranke
that flattens the projection for indexed images.
svn path=/trunk/; revision=27358
* plug-ins/file-psd/psd-load.c (add_layers): Some PSD files can
have channels where a compression method used for the channel data
is specified, but without any actual channel data. Handle this
case. Fix inspired by patch from Chris Mohler.
svn path=/trunk/; revision=27175
2008-09-08 Sven Neumann <sven@gimp.org>
* plug-ins/file-psd/psd-save.c: applied patch from Dennis Ranke
as
attached to bug #551231. Changes the PSD save plug-in to store
transparency data in the image data section. Also fixes bug
#551232
(saving an indexed image with multiple layers as PSD modifies
the
image).
svn path=/trunk/; revision=26902
Paintshop Pro)
* plug-ins/file-psd/psd-load.c (add_layers): Fix integer underflow
and only attempt to read channel data if there is any channel
data.
svn path=/trunk/; revision=26888
* plug-ins/file-psd/psd-load.c (add_layers): Also consider unknown
compression methods unsupported. This gives an error message
instead of a crash for bug #544939. The PSD loader still fails to
read the correct compression method however.
svn path=/trunk/; revision=26886
2008-08-17 Sven Neumann <sven@gimp.org>
* plug-ins/file-psd/psd-util.c (psd_set_error): changed to use
g_error_new_literal().
svn path=/trunk/; revision=26617
2008-08-11 Michael Natterer <mitch@gimp.org>
* configure.in: change all LIBFOO variables to FOO_LIBS for
consistency, could get rid of some variables alltogether since
PNG_CHECK_MODULES() already defined FOO_LIBS.
* tools/Makefile.am
* modules/Makefile.am
* plug-ins/file-ico/Makefile.am
* plug-ins/file-jpeg/Makefile.am
* plug-ins/file-psd/Makefile.am
* plug-ins/file-xjt/Makefile.am
* plug-ins/common/plugin-defs.pl
* plug-ins/common/mkgen.pl: changed accordingly.
* plug-ins/common/Makefile.am: regenerated.
svn path=/trunk/; revision=26498
2008-08-11 Michael Natterer <mitch@gimp.org>
* plug-ins/bmp/*
* plug-ins/faxg3/*
* plug-ins/fits/*
* plug-ins/fli/*
* plug-ins/ico/*
* plug-ins/jpeg/*
* plug-ins/psd/*
* plug-ins/sgi/*
* plug-ins/uri/*
* plug-ins/xjt/*: removed these...
* plug-ins/file-bmp/*
* plug-ins/file-faxg3/*
* plug-ins/file-fits/*
* plug-ins/file-fli/*
* plug-ins/file-ico/*
* plug-ins/file-jpeg/*
* plug-ins/file-psd/*
* plug-ins/file-sgi/*
* plug-ins/file-uri/*
* plug-ins/file-xjt/*: and moved them here. Changed executable
names to "file-foo".
* plug-ins/Makefile.am: changed accordingly.
* plug-ins/common/*: rename all file plug-ins to file-foo.c. Get
rid of the names "poppler" and "postscript" and call them
"file-pdf" and "file-ps" because the conflict with standard
autofoo targets is gone.
* plug-ins/common/plugin-defs.pl: changed accordingly.
* plug-ins/common/mkgen.pl: make sure cflags variables are named
"PLUG_IN_NAME_CFLAGS" and not "PLUG-IN-NAME_CFLAGS"
* plug-ins/common/Makefile.am: regenerated.
* configure.in: change folders and variable names to match above
changes.
svn path=/trunk/; revision=26494
Michael Natterer