This argument should actually say "Do not store premultiplied channel
values", which is what the TIFF spec calls "Unassociated alpha" (vs.
"associated alpha" when values are stored premultiplied by alpha).
Now I can see where the current description is coming from, which is
that any color with alpha 0 (totally masked) ends up as RGBA value (0,
0, 0, 0), in other words, the color information is completely lost. Yet
this label is not very helpful to understand what the checkbox really
does. I decided to not just change it altogether as people would have
gotten used to this for years, but at least adding completary
information in API and tooltip in GUI.
Several en_GB to en_US.
Also "Show a preview of the transform_grided image". "grided" should be
"gridded", but I also have a problem with the underscore. Should it be
"transform-gridded"? Even so, does it really make sense?
I chose to just read "Show a preview of the transformed image", which I
think is simpler and the most understandable (we don't need to leak the
implementation with a transform grid into the human read text IMO). If
anyone think that was not the right choice, feel free to propose
otherwise.
Thanks to Bruce Cowan for noticing these.
(cherry picked from commit f9c170dfbd)
...export dialogs
Remove the "Advanced" expanders from the PNG and TIFF export
dialogs. This does not reorder anything in the GUI yet, the
dialogs are still ugly.
Though we display the frame delay as milliseconds, it is actually stored
as unsigned centiseconds in GIF. This means that displaying milliseconds
can be misleading since we round every value to tens and it also means
that 10ms is the lower delay allowed. This limitation is in the GIF
format.
Other animation formats may not have this limitation and we try and keep
consistent export UIs. Also the layer tagging for animation uses "ms"
syntax. So I just keep the delay entry as ms, but sets a lower allowed
value and makes it "snaps to ticks" (i.e. snaps to 10 ms increments).
Finally I add a tooltip to the field saying "GIF supports hundredths of
a second precision."
Hopefully this should make things clearer and not mislead people about
what the GIF format allows.
When working in high bitdepth, manually changing precision to 8bit or 16bit is
an extraenous step, this adds a conversion step - but doesn't permit dithering
- and also doesn't permit using the palette modes of PNG. However it makes
workflows with single precision linear floating point much more usable.
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
Add an 'As Animation' toggle to the GIF export options. If checked,
the GIF will be written as an animation. Only enable it on images with
more than on layer though. Add the new GIFSaveVals as_animation member
last so we don't break gimp_get_data() of old data. The fix moves the
GIF options fetching to *before* gimp_export_image(). If as-animation,
we simply pass GIMP_EXPORT_CAN_HANDLE_LAYERS to capabilities so the
layers are kept.
To give us experience with Glade + GtkBuilder, use it for the save
dialog in the PNG plug-in. The layout is as good as
identical. Mnemonics still works and strings are still translated.
