mirror of https://github.com/GNOME/gimp.git
139 lines
6.1 KiB
Plaintext
139 lines
6.1 KiB
Plaintext
JPEG loading and saving file filter for the GIMP
|
|
-Peter Mattis
|
|
|
|
This filter is heavily based upon the "example.c" file in libjpeg.
|
|
In fact most of the loading and saving code was simply cut-and-pasted
|
|
from that file. The filter, therefore, also uses libjpeg.
|
|
|
|
--------------------------------------------------------------------------
|
|
15-NOV-04 - add support for EXIF JPEG thumbnail reading and writing
|
|
- S. Mukund <muks@mukund.org>
|
|
|
|
Digital cameras store a TIFF APP1 marker that contains various
|
|
parameters of the shot along with a thumbnail image.
|
|
|
|
|
|
--------------------------------------------------------------------------
|
|
22-JUN-03 - add support for keeping EXIF information
|
|
- Dave Neary <bolsh@gimp.org>
|
|
|
|
This is little more than a modified version fo a patch from the
|
|
libexif owner (Lutz Muller) which attaches exif information to
|
|
a GimpImage, and if there is infoprmation available at save
|
|
time, writes it out. No modification of the exif data is
|
|
currently possible.
|
|
|
|
|
|
|
|
--------------------------------------------------------------------------
|
|
4-SEP-01 - remove the use of GtkText
|
|
- DindinX <David@dindinx.org>
|
|
|
|
The new version of GTK+ does not support GtkText anymore.
|
|
I've just replaced the one used for the image comment by
|
|
a GtkTextView/GtkTextBuffer couple;
|
|
|
|
|
|
|
|
--------------------------------------------------------------------------
|
|
22-DEC-99 - volatiles added
|
|
- Austin Donnelly <austin@gimp.org>
|
|
|
|
When gcc complains a variable may be clobbered by a longjmp or
|
|
vfork, it means the following: setjmp() was called by the JPEG
|
|
library for error recovery purposes, but gcc is keeping some
|
|
variables in registers without updating the memory locations on the
|
|
stack consistently. If JPEG error recovery is every invoked, the
|
|
values of these variable will be inconsistent. This is almost
|
|
always a bug, but not one that's commonly seen unless JPEG recovery
|
|
code is exercised frequently. The correct solution is to tell gcc
|
|
to keep the stack version of the affected variables up to date, by
|
|
using the "volatile" keyword. Here endeth the lesson.
|
|
|
|
|
|
|
|
--------------------------------------------------------------------------
|
|
21-AUG-99 - Bunch O' Fixes.
|
|
- Adam D. Moss <adam@gimp.org>
|
|
|
|
We now correctly create an alpha-padded layer for our preview --
|
|
having a non-background non-alpha layer is a no-no in GIMP.
|
|
|
|
I've also tweaked the GIMP undo API a little and changed the JPEG
|
|
plugin to use gimp_image_{freeze,thaw}_undo so that it doesn't store
|
|
up a whole load of superfluous tile data every time the preview is
|
|
changed.
|
|
|
|
|
|
|
|
--------------------------------------------------------------------------
|
|
21-AUG-99 - Added support for JPEG previews, subsampling,
|
|
non-baseline JPEGs, restart markers and DCT method choice
|
|
- Steinar H. Gunderson <sgunderson@bigfoot.com>
|
|
|
|
A small preview appears and changes according to the changes to the
|
|
compression options. The image itself works as a much bigger preview.
|
|
For slower machines, the save operation (not the load operation) is
|
|
done in the background, with a standard GTK+ idle loop, which turned
|
|
out to be the most portable way. Win32 porters shouldn't have much
|
|
difficulty porting my changes (at least I hope so...).
|
|
|
|
Subsampling is a pretty obscure feature, but I thought it might be nice
|
|
to have it in anyway, for people to play with :-) Does anybody have
|
|
any better suggestions than the ones I've put in the menu? (See wizard.doc
|
|
from the libjpeg distribution for a tiny bit of information on subsampling.)
|
|
|
|
A baseline JPEG is often larger and/or of worse quality than a non-baseline
|
|
one (especially at low quality settings), but all decoders are guaranteed
|
|
to read baseline JPEGs (I think). Not all will read a non-baseline one.
|
|
|
|
Restart markers are useful if you are transmitting the image over an
|
|
unreliable network. If a file gets corrupted, it will only be corrupted
|
|
up to the next restart marker. Of course, if there are no restart markers,
|
|
the rest of the image will be corrupted. Restart markers take up extra
|
|
space. The libjpeg developers recommend a restart every 1 row for
|
|
transmitting images over unreliable networks, such as Usenet.
|
|
|
|
The DCT method is said by the libjpeg docs to _only_ influence quality vs.
|
|
speed, and nothing else. However, I've found that there _are_ size
|
|
differences. Fast integer, on the other hand, is faster than integer,
|
|
which in turn is faster than FP. According to the libjpeg docs (and I
|
|
believe it's true), FP has only a theoretical advantage in quality, and
|
|
will be slower than the two other methods, unless you're blessed with
|
|
very a fast FPU. (In addition, images might not be identical on
|
|
different types of FP hardware.)
|
|
|
|
...and thus ends my additions to the JPEG plug-in. I hope. *sigh* :-)
|
|
|
|
|
|
|
|
|
|
--------------------------------------------------------------------------
|
|
11-JAN-99 - Added support for JPEG comments and Progressive saves.
|
|
-pete whiting <pwhiting@sprint.net>
|
|
|
|
Comments of size up to 32k can be stored in the header of jpeg
|
|
files. (They are not compressed.) The JPEG specs and libraries
|
|
support the storing of multiple comments. The behavior of this
|
|
code is to merge all comments in a loading image into a single
|
|
comment (putting \n between each) and attach that string as a
|
|
parasite - gimp-comment - to the image. When saving, the image is
|
|
checked to see if it has the gimp-comment parasite - if so, that is
|
|
used as the default comment in the save dialog. Further, the other
|
|
jpeg parameters (quality, smoothing, compression and progressive)
|
|
are attached to the image as a parasite. This allows the
|
|
parameters to remain consistent between saves. I was not able to
|
|
figure out how to determine the quality, smoothing or compression
|
|
values of an image as it is being loaded, but the code is there to
|
|
support it if anyone knows how. Progressive mode is a method of
|
|
saving the image such that as a browser (or other app supporting
|
|
progressive loads - gimp doesn't) loads the image it first gets a
|
|
low res version displayed and then the image is progressively
|
|
enhanced until you get the final version. It doesn't add any size
|
|
to the image (actually it often results in smaller file size) - the
|
|
only draw backs are that progressive jpegs are not supported by some
|
|
older viewers/browsers, and some might find it annoying.
|
|
|
|
|
|
|