Anyone know of a good command-line utility for doing lossless JPEG transforms? Preferrably under as liberal a license as possible, since I want to integrate it into my own software eventually. For now though I'd just like something that runs on the command line and transforms JPEGs quickly and without fuss.
jpegtran.exe, included in the standard jpeg distribution.
usage: jpegtran [switches] inputfile outputfile
Switches (names may be abbreviated):
-copy none Copy no extra markers from source file
-copy comments Copy only comment markers (default)
-copy all Copy all extra markers
-optimize Optimize Huffman table (smaller file, but slow compression)
-progressive Create progressive JPEG file
Switches for modifying the image:
-grayscale Reduce to grayscale (omit color data)
-flip [horizontal|vertical] Mirror image (left-right or top-bottom)
-rotate [90|180|270] Rotate image (degrees clockwise)
-transpose Transpose image
-transverse Transverse transpose image
-trim Drop non-transformable edge blocks
Switches for advanced users:
-restart N Set restart interval in rows, or in blocks with B
-maxmemory N Maximum memory to use (in kbytes)
-outfile name Specify name for output file
-verbose or -debug Emit debug output
Switches for wizards:
-scans file Create multi-scan JPEG per script file
Thanks! I'll check that out.
Tip: for optimum results, add -trim when doing a -rotate.
Haven't played with it myself, but I assume that if those edge-blocks are "non-transformable", they'd get munged anyway if your -rotate. I'd let it pass as "lossless". The JPEG algo isn't tainting the image data.
(Hmm, I suppose the non-transformable blocks are anything overhanging the 2x2 macroblock? Unless JPEG supports having less-than-full-size macroblocks on the top or left edges, I can see why it'd need to drop them.)
> if those edge-blocks are "non-transformable", they'd get munged anyway if your -rotate
They end up appended to the other side of the image. At least it's reversible.
I assume that building this function into an image viewer means it'll be overwriting the original, so throwing away part of the image unexpectedly isn't good behaviour. Maybe you should limit it to "perfect" transformations only.
> Unless JPEG supports having less-than-full-size macroblocks on the top or left edges, I can see why it'd need to drop them.
I came across one image that appeared to be padded with blank space instead of being trimmed. That might be an alternative.
If it's an image viewer you can just implement the functionality without writing a file.
Padding with space seems a good idea. Even better is extrapolating to get a full macroblock (just copy the edge row of pixels). I think hardly anyone would notice.
If you're not writing a file, why is it important to keep it compressed?
Yes, I am most definitely writing to a file. The common usage here would be for taking a set of digital photos or scans and rotating them to their correct orientation.
Well, I did check out jpegtran. And guess what I found? See, the EXIF metadata in JPEGs can contain an orientation tag that says how the camera was turned when taking the picture, which some viewers use to automatically turn the image the right way, and...
http://sylvana.net/jpegcrop/exif_orientation.html
>jpegtran does not change the Orientation Tag when performing lossless transformations. The reason is that it cannot rely on the validity of the stated information, and it could potentially confuse other applications if it would mistakenly rely on the information and change it appropriately.
>Furthermore, if you want automatic correction, then you must examine the field first to decide whether to call jpegtran at all and if yes with which transformation option.
> Therefore, it has been found that the best solution to the problem would be to handle the examination and manipulation of the Exif Orientation field by separate utilities, not jpegtran.
Translation: Because the orientation tag in the EXIF data of a JPEG file might be wrong, we're going to ignore it, thus making sure it will actually be wrong after running the program. Also, we're not going to do automatic rotation based on the orientation tag, because then we'd actually have to do just that.
I have no idea what goes on in the heads of these people. Luckily, I finally found this:
http://linux.bytesex.org/fbida/
> exiftran
> command line tool to do lossless transformations of JPEG images. Works much like jpegtran, but unlike jpegtran it does not ignore the EXIF data ;)
When others are making alternate versions of your program and making snide remarks in the one-line description of it, maybe that's some sort of hint.
> thus making sure it will actually be wrong after running the program
By default it discards all metadata except for the "comment" parts. Not that that's any better...
I was being generous by avoiding mentioning that.