No announcement yet.

Reorient Image Using JPG Lossless Operation

  • Filter
  • Time
  • Show
Clear All
new posts

    Reorient Image Using JPG Lossless Operation

    I'm hoping for a little guidance on using the JPG Lossless Operation function to re-orient many of my images. I am using IrfanView 4.0 with Windows XP SP2.

    I use the Thumbnail view to open the folder and view all the images. I select them all, then choose JPG Lossless Operations -> Lossless Transformation with Selected Files. The options selected are:

    Auto-rotate according to EXIF Orientation
    Optimize JPG file
    Apply Original EXIF date/time to new file
    Keep all APP markers (default)

    After running the transformation, the images are now orientated properly, but I've noticed that the files sizes are now smaller. Does this mean that the images have in fact "lost" something (I assume as part of the JPG optimization) even though it is to be "lossless"?

    If I restore the originals and the run it again, this time with the Optimize JPG option unchecked, the file sizes end up being larger after the transformation than they were before it.

    What is the best way to re-orient large numbers of images without changing the original images themselves? Or by changing the EXIF orientation info, am I in fact changing the original?

    Should the JPG Lossless Operations be changing the file sizes from what they were orginally?

    What I am trying to do is to reorient the images properly, then run a batch conversion resize in order to get them in a size better suited for a website (800x600). (The original files are 2592x1944.) Perhaps there is a better way I should be going about this process?


    JPG conversion and saving is done by a compression algoritm, no matter 100 % or 'lossless'. So I think it's hardly possible
    to maintain the exact bytesize of the original file. Even an uncompressed BMP file rotated 90 degrees becomes a different filesize.
    Sometimes The One better way isn't a single solution, but consists of more ways in a sequence.
    So more 'subroutines' to do in the process. To keep control of the quality you demand.
    It's more work, so if you're in a hurry, and prefer the quick way, accept the 'loss' of various elements.

    My rule nr zero in these cases : first convert the originals to an uncompressed format, do the editing, and when finished,
    convert the results back to the desired compressed format and save. It's the way to loose as less information as possible
    during the process.

    In this case there are two subroutines :
    1) If needed, rotating the original according to the EXIF information.
    2) Resizing from 2592x1944 to 800x600
    So batch run 1) could be a combination of rotation and converting to e.g. BMP.
    And batch run 2) could be a combination of resizing the BMP's and converting them to a lossless JPG.

    If you really want quality kept, then the resizing of 2592 to 800 is a huge step in dimension. With inevitable losses.
    Better divide this with an extra step. Try for example to resize first to "Half" and apply the 'sharpen' function, before resizing to the final 800.
    Rest In Peace, Sam!


      JPEG rotate is lossless, except if the image dimensions are not multiples of the block size (8px, or 16px if chroma subsampling is used). In this case some software will drop the incomplete blocks, other migth write garbage instead. The coded JPEG data can be further packed using different lossless compressors: Huffman encoding of a little variable efficiency and arithmetic coding. Arithmetic coding is mostly unsupported by applications. Variable file sizes result from how the app applies huffman algorithm. A (lossless) zip file created in 2 different programs such as WinRar and 7-Zip will also result in different sizes. The same can be said about PNG.

      If you are going to perform further edits to your images, such as scaling, it makes no sense to use lossless JPEG rotation.


        Thanks for the feedback.

        Since the primary reason for resizing any of my images is to throw them up on web pages or send them off via email, I can leave with losing a few pixels here and there. For what they are being resized for, quality is of the utmost importance.

        The primary reason for me presenting the question is as follows. When I copy images off my camera, I usually preserve them as a 'master' copy. I even set them to read-only so that nobody else inadvertently modifies them. These images are often a mix of portrait and landscape orientations. What I was hoping to with the JPG Lossless Operations was to at least auto-rotate the images according to the EXIF info, but while still preserving them as the 'masters'. Since the image is being changed ever so slightly with the JPG Lossless, I guess they can no longer be considered the same as the 'master' copy.

        I'll just stick with a method of copying the JPGs that I want to manipulate off to a working directory, reorient and resize them there, and leave the 'masters' alone. No big deal.

        Thanks again.


          Not handling originals but copies is the best thing anyway.
          Rest In Peace, Sam!



            I tried this "famous" lossless operation with a test file 518*774 which I rotated 90° clockwise using IrfanView. The result is an image 768*518. There are 6 columns of pixels that are lost

            I opened the original and the transformed image in the Gimp, restored the orientation (90 anti clockwise) and superposed them on two layers. I asked the difference. It should be zero or black. You can see the real result in the attached file (PNG), with a very strong contrast

            Attached Files
            Before you post ... fill in your OS and IV version in your profile.


              Lost pixels are to be expected. JPEG will not rotate incomplete macroblocks. Losing at average 15 rows makes no big difference in 6-10 megapixel picture. You will lose nothing if your camera outputs resolution divisable by 16 (or 8 without subsampling).

              I repeated the test with this image. I rotated the file RIGHT in (1) JPEGCrop, (2) IrfanView and saved as PNG. Loaded the rotated JPEG and PNG files in Paint Shop Pro. The difference was zero, except the lost pixels of course.

              There is no need to ridicule lossless rotation.

              Last edited by j7n; 17.08.2007, 02:00 PM.


                Hi j7n,

                Thanks for your comment about macroblocks. I didn't know.
                It wasn't my purpose to ridiculize lossless rotation and I am sorry if it was your feeling.
                But strictly speaking it remains that "lossless transformation" doesn't describe correctly what happens.
                I also note that there are différences between your images rotate.jpg and the two others. Here is the difference with result-jpegrotate.jpg, once again with contrast highly enhenced. The difference is zero for most pixels but amounts to 1 unit (in the range 0-255) for quite a noticeable number of pixels.
                Now, it is true that one lossless rotation followed by the inverse lossless rotation gives back exactly the original image, except some full rows of pixels.

                Before you post ... fill in your OS and IV version in your profile.


                  Hi Laurent,

                  you were right. I apologize. After repeating the test I came to the same conclusion that there are differences in range of 2.

                  Thank you for pointing out that by rotating back it is possible to recover the original data. Indeed, I produced not only exact decoded pictures but completely bit identical files. Now could the rotation itself be called lossless if it is reversible?

                  I'm also curious if it is possible to increase the precision of a JPEG decoder so that there would be no detectable differences in 8-bits output?


                    Hi j7n,

                    Maybe the best conclusion is that that the transformed image is not exactly the same as the original one, but that the transformation is really lossless because the original can be rebuilt, except for the irreversible loss of the last rows or columns of pixels (size mod 16 or size mod 8).

                    Before you post ... fill in your OS and IV version in your profile.