Image Storage - Optimization
chipp at chipp.com
Mon Mar 20 16:08:55 CST 2006
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).
More information about the use-livecode