Image Storage - Optimization

[Chipp Walters]

Hi Sivakatirswami,

Never did hear how you guys did in that horrible flood last week. Hope 
all is OK!

Regrading what I think you did and the subsequent results:

First, when describing importing an image, it's a good idea to give 
pixel dimenstions and not inches. So, I assume at 72dpi an 3 x 5 image 
is 216 x 360 which is 227.8K raw imagedata. The reason it was 80K as a 
JPG file was due to the JPG compression. When saving a raw image in a 
stack, Rev applies its own non-destructive compression to it reducing it 
from 227K to 54K. The compression applied is not gZip as gZip is not 
optimized for compressing images.

Just doing the following blows up the stack to 305K:

set the altImageData of this stack to the imageData of img 1
delete img 1

This is because the imagedata is a pixel for pixel exact representation 
of what the image is. No compression.

Starting over and putting:

set the altImageData of this stack to compress (the imageData of img 1)
delete img 1

reveals a stack 71K in size. You see, the compress function doesn't work 
as good as the built-in image compression which created a 54K stack.

Scaling the image larger doesn't add anything to the stack size IF you 
don't store the image as imageData, but IF YOU DO capture the imagedata, 
then you are accessing that many more pixels and that much more 
imageData, thus creating a larger stack. Though the image itself has 
gained no higher resolution (image quality) as you can't make an image 
larger and increase resolution without some tricky algorithms.

The whole export thing being smaller you have going on is due only to 
the JPEG compression setting.

Also remember, if you're resizing DOWN (as in creating thumbnails) 
setting the resizeQuality of an image to best enables bilinear sampling, 
which looks better than the default nearest neighbor sampling (though it 
takes slightly longer).

HTH,

Chipp