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.
The plug-in already makes a copy of the cinfo struct for asynchronous
save, but it seems that somewhere inside cinfo, a pointer points to
another region in this struct. So, everything is copied as-is, and
the pointer ends up pointing to somewhere in the save_image() stack
which is gone when that function returns.
This patch cancels the GSource for background_jpeg_save() and calls it
synchronously to free resources. Without this patch, multiple GSources
for background_jpeg_save() get setup and result in a crash.
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.
Added a function to merge the Exif data into the xmp model. The function
is using the image id and to access the Exif data parasite. For each
Exif property a corresponding value in the XMP model is created.
2009-03-07 Sven Neumann <sven@gimp.org>
* plug-ins/file-jpeg/jpeg-load.c (load_image)
* plug-ins/file-jpeg/jpeg-save.c (save_image): need to finish
the
progress update.
svn path=/trunk/; revision=28118
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
2008-12-28 Sven Neumann <sven@gimp.org>
Bug 563985 – jpg save dialog: "cancel" is treated like "commit"
for settings
* plug-ins/file-jpeg/jpeg.c (run): only attach the comment and
settings to the image if the save was successful.
svn path=/trunk/; revision=27843
