Jpegcrop Preferences and Options description

Most Jpegcrop options correspond to the jpegtran commandline
switches which are explained in the usage.txt file of the
Independent JPEG Group v9 distribution.

Starting with interactive support for the jpegtran -crop option,
Jpegcrop has now developed to a nearly complete user interface replacement
for jpegtran.

Most essential jpegtran options are provided with Jpegcrop now,
except some very special switches.

Entropy Coding Method

The Entropy Coding Method is the final *lossless* part of the JPEG
compression scheme. It does *not* affect the image quality. You can
transcode between different methods without image degradation.

Huffman default uses predefined Huffman tables for the
final entropy coding stage as given in the JPEG standard.

Huffman optimized corresponds to the cjpeg and
jpegtran -optimize switch.
Here is what the IJG v9 usage.txt file says about this switch:

Perform optimization of entropy encoding parameters.
Without this, default encoding parameters are used.
-optimize usually makes the JPEG file a little smaller,
but cjpeg runs somewhat slower and needs much more
memory. Image quality and speed of decompression are
unaffected by -optimize.

The -optimize option to cjpeg is worth using when you are making a "final"
version for posting or archiving. It's also a win when you are using low
quality settings to make very small JPEG files; the percentage improvement
is often a lot more than it is on larger files. (At present, -optimize
mode is always selected when generating progressive JPEG files.)

In the jpegtran and Jpegcrop context, using this option has less
downsides than in cjpeg. The higher memory usage is inherent to
jpegtran operation anyway, and the additional runtime is very
short.
So if you prefer smaller output file sizes with minor operation
penalty in Huffman mode, just turn this switch on.

Arithmetic coding provides the best compression results, i.e.
smallest file sizes, and is therefore the preset default setting.
CAUTION: arithmetic coded JPEG is not yet widely implemented, so many
decoders will be unable to view an arithmetic coded JPEG file at all.

Progressive Coding

This switch turned on creates a progressive JPEG file.
Here is what the IJG v9 usage.txt file says about this switch:

The -progressive switch creates a "progressive JPEG" file. In this type of
JPEG file, the data is stored in multiple scans of increasing quality. If the
file is being transmitted over a slow communications link, the decoder can use
the first scan to display a low-quality image very quickly, and can then
improve the display with each subsequent scan. The final image is exactly
equivalent to a standard JPEG file of the same quality setting, and the total
file size is about the same --- often a little smaller.

Marker Copy Option

The Marker Copy Option controls what to do with "extra" markers, such as
comment or Exif blocks.

None: Copy no extra markers from source file. This setting
suppresses all comments and other metadata in the source file.

Comments: Copy only comment markers. This setting copies
comments from the source file, but discards any other metadata.

All: Copy all extra markers. This setting preserves metadata found in
the source file, such as JFIF thumbnails, Exif data, and Photoshop settings.
In some files these extra markers can be sizable. Note that this option will
copy thumbnails as-is; they will not be transformed.

The preset default setting is "All" for safety, so you won't lose anything
unless otherwise specified.

Copy File Time

Many people prefer to keep not only all extra markers, but also the timestamp
of the transformed file in the filesystem. So the default setting for this
switch is on. In the off state the written file gets the creation timestamp
as usual.

Processing Mode

The Processing Mode controls the handling of abnormal conditions while
reading the source file.

Abort on warnings aborts processing when an abnormal condition occurs.
This is important in case of overwriting the same source file with the
transformed file: The source file will still be there unchanged in this case.
On the other hand, if you want to process a file with abnormal, but non-fatal
error conditions, nothing would be written if this switch is turned on.

Ignore warnings continues processing in case of non-fatal error
conditions, providing an output also for abnormal input files.
The danger of this setting is when you overwrite your input with the output
- possibly damaging your input and losing data.

The Zoom Reload switch controls the Zoom options. With Zoom Reload turned
off, images are resized from the loaded in-memory bitmap pixelwise when
redrawing the window. With Zoom Reload turned on, images are reload from
storage media and resampled directly in the JPEG (DCT) domain rather than
spatial domain when changing the zoom value, thus providing a more pleasing
image look in the target resolution. In this case the in-memory bitmap holds
the image in the display resolution, yielding a 1:1 window redraw for any
zoom size with enabled Zoom Reload.
The preset default setting is ON for better image display in zoom mode.

Save

The parameter settings of the Preferences dialog may be saved in a jpegcrop.inf
file for persistent usage.

The settings under the Options menu title differ from the Preferences
settings in that they affect the user interaction, instant image display,
and resulting file output.
The display related settings of the Preferences section (16-Bit
FixPix Dither and Zoom Reload) have no instant effect, but only for the next
Load or Zoom View operation, and do not affect file output.

Save With Zoom

When saving apply selected zoom setting.
CAUTION:
An implementation of the JPEG SmartScale extension is required for this feature.
SmartScale enabled JPEG is not yet widely implemented, so many decoders
will be unable to view a SmartScale extended JPEG file at all.

Endpoint Snap

While dragging the frame snap the endpoint on the block grid.
This is recommended and is therefore the default setting.
It results in complete MCUs in the output image, which is
advantageous under certain conditions.

Transform Trim Edges

Drop non-transformable edge blocks.
Here is what the IJG v9 usage.txt file says about this switch:

The transpose transformation has no restrictions regarding image dimensions.
The other transformations operate rather oddly if the image dimensions are not
a multiple of the iMCU size (usually 8 or 16 pixels), because they can only
transform complete blocks of DCT coefficient data in the desired way.

jpegtran's default behavior when transforming an odd-size image is designed
to preserve exact reversibility and mathematical consistency of the
transformation set. As stated, transpose is able to flip the entire image
area. Horizontal mirroring leaves any partial iMCU column at the right edge
untouched, but is able to flip all rows of the image. Similarly, vertical
mirroring leaves any partial iMCU row at the bottom edge untouched, but is
able to flip all columns. The other transforms can be built up as sequences
of transpose and flip operations; for consistency, their actions on edge
pixels are defined to be the same as the end result of the corresponding
transpose-and-flip sequence.

For practical use, you may prefer to discard any untransformable edge pixels
rather than having a strange-looking strip along the right and/or bottom edges
of a transformed image. To do this, add the -trim switch.

Obviously, a transformation with -trim is not reversible, so strictly speaking
jpegtran with this switch is not lossless. Also, the expected mathematical
equivalences between the transformations no longer hold. For example,
"-rot 270 -trim" trims only the bottom edge, but "-rot 90 -trim" followed by
"-rot 180 -trim" trims both edges.

Grayscale Reduction

Force grayscale output.
Here is what the IJG v9 usage.txt file says about this switch:

This option discards the chrominance channels if the input image is YCbCr
(ie, a standard color JPEG), resulting in a grayscale JPEG file. The
luminance channel is preserved exactly, so this is a better method of reducing
to grayscale than decompression, conversion, and recompression. This switch
is particularly handy for fixing a monochrome picture that was mistakenly
encoded as a color JPEG. (In such a case, the space savings from getting rid
of the near-empty chroma channels won't be large; but the decoding time for
a grayscale JPEG is substantially less than that for a color JPEG.)