...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.
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.
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.
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.
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
This was discussed in #gimp. The old label was "Frequency (rows)"
which is misleading. This field is basically converted by libjpeg
to another value called a restart interval which is stored in a
JPEG file. The restart interval specifies after how many MCUs
the restart (syncronization) marker appears in the bitstream.
It is not easy to explain to a layperson what an MCU is.
The value in the dialog specifies after how many *MCU rows* the
restart marker appears. This is a libjpeg thing, and libjpeg
converts it to the restart interval.
I have merely renamed the text label of the field and PDB
description as the current text implies pixel rows which is not
the case.
A better alternative is to use the restart interval (in MCUs,
not MCU rows) as saved in the file itself, which more people
than users of libjpeg would understand. But even that setting
is not something that can easily be explained to a layperson.
This was discussed in #gimp. This would no longer result in strictly
baseline JPEGs, but progressive mode has been supported for about
a decade in browsers and libjpeg now.
Progressive mode brings two advantages: (1) Medium to large images get
decent space savings to due to coding of large sequences of
zero coefficients, and (2) The images load progressively in a browser
which leads to better user experience when viewing medium to large
images on a website.
Those who want strictly baseline have the option to turn it off.
This was discussed in #gimp. There is no reason to have the default
option throw away such image quality in these days of large hard disks
and broadband.
