Lossless rotation file size changes

Discussion in 'Digital Photography' started by Keith Sheppard, Feb 4, 2004.

  1. I have now tried twice to send this. I don't know why it never arrives in
    the newsgroup. Let's try doing it as a new thread.

    This is in response to the person who was asking why "lossless" rotation
    produced a smaller jpeg file than the original...

    I just tried this with my own software which I KNOW doesn't change the jpeg
    data when you rotate. The file still got smaller. On investigation I
    discovered the reason is...

    The software in my camera does not pack the information into the jpeg file
    in the most efficient manner. I suspect this is due to limited program
    memory space in the camera. I doubt that my camera is unique in this
    respect.

    As well as the actual jpeg image, a digital photo file contains all sorts of
    other stuff (exposure information, you name it). The jpeg standard allows
    software writers a great deal of freedom as to how to pack this information
    into the file. The most efficient way is to pack it all in tightly with no
    gaps and hence no wasted space.

    It appears that cameras (at least, my camera) don't necessarily do this. To
    keep their software simple, they insert padding so that the important bits
    of information are always at the same offset within the file.

    I used my own software to do an in-situ rotation of a jpeg image and then
    rotated it back again. The resultant image was 5k smaller than the
    "straight out of the camera" version. All of this was due to discarded
    padding. The actual jpeg data had not changed.

    I also observed a slight difference in the image size when rotated through
    90 degrees compared with the unrotated. The difference was around 2k (this
    was for a 1600x1200 image). I don't know enough about jpeg to explain this
    (I am using public domain rotation code) but I don't think it has any impact
    on picture quality. Once the padding had been discarded I could rotate the
    image back and forth as often as I wanted without any further change to
    image size.

    In summary, a reduced file size does not necessarily imply reduced image
    quality. It could just be that your PC software has discarded unnecessary
    padding placed in the original file by your camera.

    If you would like a copy of my home made software, send me a personal email
    ().

    Keith
     
    Keith Sheppard, Feb 4, 2004
    #1
    1. Advertisements

  2. I think you should consider the EXIF data in the images. I know that Windows
    XP's lossless rotation loses some of Canon's extended EXIF information; the
    EXIF lines that show up in Windows' properties are kept, but it drops the ones
    it doesn't understand. There is a considerable amount of information in those
    extended lines, and I think you'll see that it makes a noticeable difference
    in the file size.

    Of course, I would like to see it tested by saving a jpg without exif and
    doing the rotation, thus removing that variable. If the file size is still
    smaller, you may be right about the wasted space, otherwise I think it's just
    the rotation program losing some of that EXIF data.
     
    Ethan Trewhitt, Feb 4, 2004
    #2
    1. Advertisements

  3. I also said something about this phenomenon, but now that you post again
    I remember an interesting story which happened recently.

    As the 'inventor' of the JPEG lossless rotation algorithm I often get
    contacted regarding corresponding problems.

    Recently I got an enquiry from somebody who rotated an image from the
    Canon 300D camera and lost about 400-500 KBytes of filesize with lossless
    rotation. I had no idea what reason could cause such major decrease,
    so he sent me the file for investigation (ouch, a typically bad bayer
    type image hurting my eyes - but aside from this...).
    After some try I did find the reason, and that was really surprising:
    After the main image the file contained a half-sized (per dimension)
    image version at the end, and it was just this redundant part which
    got lost.
    So that was an interesting discovery about the 'design' of image
    processing in a Canon camera: The camera writes an additional
    half-sized image version into the file, which does not only occupy
    a considerable amount of redundant data space, but obviously also
    costs time to process and write out to memory device.
    Asking Canon about this behaviour brought the answer that it was
    done to accelerate playback as a straining after effects for the
    aimed (dumb) user (they did so only in the 300D, not in the 10D).

    Here you have a good example how manufacturers are faking the hell
    to impress people with dubious practices, so take care!
    It is also a particular example of their image processing incompetence,
    because if they really wanted to accelerate playback with down-sized
    images, they could do much better by taking a look at the algorithms
    presented at http://jpegclub.org/djpeg/ .
    There is to see that you can easily derive a half-sized version with
    high efficiency and without redundancy from the main image - the
    algorithm rating below means that you can derive such half-sized
    image with *half* the computation cost from the main image compared
    to a normal decode from a separate half-sized compressed image!

    Regards
    Guido
     
    Guido Vollbeding, Feb 4, 2004
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.