[cnelson87]

Is there a program that will rotate, and maybe even crop, a jpeg without having to recompress? I don't care if it's for 9 or X. In the past I've used Jpegtran to "fix" jpeg packet data for streaming RealMedia / SMIL presentations, and it might do what I need, but I can't find it anymore. Any ideas or suggestions?
C.

[dampeoples]

Not sure what you mean by recompress, but preview has a rotate tool in 10.2

[godzookie2k]

graphic converter? photoshop? iPhoto?

[derien]

That's a good question. I don't think you can save as jpeg without compressing. At least, I've never seen such an option (which, admittedly, is not saying much). Theoretically, though, it seems like it could be possible depending on how the data is stored. I'd be interested to hear the answer.

[bluedog]

There is the option in some PC apps for rotating without a recompress, and I've seen in with the unix-based webinterface for a photoalbum, called 'photo album' on www.freshmeat.net (its likely also on http://www.sourceforge.net ) if you want to look for it and get it running.

I've installed it and run it on my linux server (an 7600 upgraded to G3) and it works really well.

Its definitly possible. I think iPhoto would likely take advantage of this 'lossless rotate' of a JPG file.

Anyone know the specifics whether iPhoto handles this? Or does it just take the one-time hit for rotating and keep your original around if you want to 'revert' to another orientation (which is a likely way they are doing it).

[cnelson87]

"Not sure what you mean by recompress, but preview has a rotate tool in 10.2"

"graphic converter? photoshop? iPhoto?"

Jpgs use lossy compression to keep file size low. Heavy jpg compression creates visual artifacts and "ghosting." All of these aps (well, I haven't tried iPhoto yet, but I have my doubts) recompress the jpg when saving, creating subtle but noticeable imperfections.

It seems like there should be a CL ap out there that can handle this. A jpg is just a bunch of 1s and 0s - how hard can it be to manipulate them?

The funny thing is, I swear I saw something like this on VersionTracker last week, but after doing a search I came up with zilch.

C.

[godzookie2k]

but if you are resaving the jpeg as 100% quality, i.e. no compression, isn't that same as not recompressing it?

[cnelson87]

"but if you are resaving the jpeg as 100% quality, i.e. no compression, isn't that same as not recompressing it?"

Even 100% quality is still compressing the image. 100% quality just means that is the highest quality of compression.

[jswayze]

I'm postulating here, but I would think of JPEG as a storage method, not a display method. On screen, your image is uncompressed - a bunch of sequentially stored values in the computer's memory that are dumped to the screen. AFAIK, the app doesn't store the compressed data and then uncompress it every time you perform an operation then recompress it again. I would think that once uncompressed from the JPEG file, the original compression scheme is gonzo.

In order to write the image back to disk, you'd either send a header (dimensions, color depth, etc.) then the raw data (Pixel #1 Red value, Pixel #1 Green value, #1 Blue, #2R, ... etc.) for an uncompressed image (like raw TIFF) or a header and the binary data representing the output of the compression algorithm for a compressed file.

Unless the JPEG header includes an orientation parameter, it seems to me that it would be impossible to rotate the image and save it without re-compressing it in a completely different manner.

If there actually is a way to do this, I'd be interested to know how it's done. I'll have to go through my graphics books when I get home from work...

I hope this makes sense...

-Jeff

[cnelson87]

Jeff / jswayze,

Makes perfect sense. Something like changing the jpgs orientation info in the file header is exactly what I'm asking about.

C.

[jswayze]

Well, at the risk of taking up too much space, here's some info from my graphics bible: "Encyclopedia of Graphics file Formats" regarding the JPEG header:

Although JFIF files do not possess a formally-defined header, the SOI and JFIF APP0 markers taken together act as a header in the following marker segment structure:

Code:
typedef struct _JFIFHeader
{
  BYTE SOI[2];          /* 00h  Start of Image Marker     */
  BYTE APP0[2];         /* 02h  Application Use Marker    */
  BYTE Length[2];       /* 04h  Length of APP0 Field      */
  BYTE Identifier[5];   /* 06h  "JFIF" (zero terminated) Id String */
  BYTE Version[2];      /* 07h  JFIF Format Revision      */
  BYTE Units;           /* 09h  Units used for Resolution */
  BYTE Xdensity[2];     /* 0Ah  Horizontal Resolution     */
  BYTE Ydensity[2];     /* 0Ch  Vertical Resolution       */
  BYTE XThumbnail;      /* 0Eh  Horizontal Pixel Count    */
  BYTE YThumbnail;      /* 0Fh  Vertical Pixel Count      */
} JFIFHEAD;

SOI is the start of image marker and always contains the marker code values FFh D8h.

APP0 is the Application marker and always contains the marker code values FFh E0h.

Length is the size of the JFIF (APP0) marker segment, including the size of the Length field itself and any thumbnail data contained in the APP0 segment. Because of this, the value of Length equals 16 + 3 * XThumbnail * YThumbnail.

Identifier contains the values 4Ah 46h 49h 46h 00h (JFIF) and is used to identify the code stream as conforming to the JFIF specification.

Version identifies the version of the JFIF specification, with the first byte containing the major revision number and the second byte containing the minor revision number. For version 1.02, the values of the Version field are 01h 02h; older files contain 01h 00h or 01h 01h.

Units, Xdensity, and Ydensity identify the unit of measurement used to describe the image resolution. Units may be 01h for dots per inch, 02h for dots per centimeter, or 00h for none (use measurement as pixel aspect ratio). Xdensity and Ydensity are the horizontal and vertical resolution of the image data, respectively. If the Units field value is 00h, the Xdensity and Ydensity fields will contain the pixel aspect ratio (Xdensity : Ydensity) rather than the image resolution. Because non-square pixels are discouraged for portability reasons, the Xdensity and Ydensity values normally equal 1 when the Units value is 0.

XThumbnail and YThumbnail give the dimensions of the thumbnail image included in the JFIF APP0 marker. If no thumbnail image is included in the marker, then these fields contain 0. A thumbnail image is a smaller representation of the image stored in the main JPEG data stream (some people call it an icon or preview image). The thumbnail data itself consists of an array of XThumbnail * YThumbnail pixel values, where each pixel value occupies three bytes and contains a 24-bit RGB value (stored in the order R,G,B). No compression is performed on the thumbnail image.

Bottom line, from what I can tell, is that there is no orientation field in the header. Sorry, but it doesn't look good for rotation without recompressing.

Good luck,

Jeff