Image Storage - Optimization

Sivakatirswami katir at hindu.org
Mon Mar 20 05:36:36 EST 2006


This is a spin off from my earlier thread on DRM for images in  
stacks.  In experiments with putting compressed imageData into a  
custom prop I discovered it bloated the size of the stack. I then  
tested "recovery" of that data to an original jpeg size, with some  
very interesting results, possibly "stumbling" on an optimization  
feature, I may need my eyes tested, or at least try this same test on  
images with intricate "edges" and  with photos of peoples faces...

1) import 3 X 5 imag 80k .jpeg (in this case  NASA space shot)
2) Scale the image way up on the card  (4 times)  so it becomes the  
whole background  of the card
3) save stack: stack size: 80 K
4) set the uStuff of this card to compress(the imageData of img 1)
put "" into img 1
5) save stack: stack size 1.2meg! ouch!
6) try to recover:
7) set the imageData of img 1 to decompress(the uStuff of this card)
8) scale down the image to 3 X 5
9) set JPEGcompression to 40
10) export image 1 to someFile.jpg as JPEG; delete image 1
11) export image on disk is only 27K!
12) import someFile.jpg back into the stack, save stack
13) stack size 27 k!

  I immediately assume "we probably have terrible degradation from  
multiple interpolations..the small stack must look awful next to the  
stack with the original image" and set about checking that.

Make new stack and import the original 80K image... open two stack  
side by side: one is 80K in size and the other is 27 K in size, they  
both started out with the same image as data..

I cannot see *any* difference in the two images! but one stack is 80K  
and the second one is 27K.

  Either some jpeg artifact desensitivity filters got stuck in my  
eyes and I am missing the differences that some more critical eye  
might see. Or  I may have  stumbled on some algorithm for optimizing  
files  sizes for imported images. I'm sure there are many underlying  
variables I am not seeing in particular.  But if it is true, it's has  
some major implications for image storage and stack size optimization.

Sivakatirswami










More information about the use-livecode mailing list