Re: [Flashcoders] Simple compression algo?

2008-02-05 Thread Dave Mennenoh
Hi Juan - I don't think it's assigning the string that's slow. It's calling 
sendAndLoad that is slow, because I think when you make the call the data is 
urlencoded or something. I've already found that, and am not calling it. I 
was simply outputting the before and after string lengths to see how Base64 
and LZW worked. Could be the class I was using, but either way it was way 
too slow to be useful to me. My simple array compressor is nearly instant 
and on some images it's getting me an 80%+ reduction in the array size, 
which is more than enough for my needs. On average it's only around a 20% or 
so reduction, but that's still good enough as my images are not very big.
I think you're idea is great, and for AS3 a definite, but in AS2 I fear it's 
just going to be too slow. Plus, I've already spent far too long on this 
little aside and should be moving on, though I do enjoy these kinds of 
things. If you want to see some of my test results, I posted a little 
article on my blog: www.dmennenoh.blogspot.com


Thanks much!


Dave -
Head Developer
http://www.blurredistinction.com
Adobe Community Expert
http://www.adobe.com/communities/experts/ 


___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


Re: [Flashcoders] Simple compression algo?

2008-02-05 Thread Juan Pablo Califano
I don't think it's assigning the string that's slow. It's calling
sendAndLoad that is slow, because I think when you make the call the data is
urlencoded or something

Yes, you're probably right. I thought maybe the string was encoded as soon
as it assigned, but it makes more sense that the encoding is done when the
data is actually sent.

If you're code already works, great, go with it. I was just suggesting
another approach, but I understand what you mean. You've invested
a considerable time on it and already works pretty good for your actual
needs, so it makes no sense to try another method that could be worse
performance-wise.

I've taken a glimpse at your code, by the way. I like that it's simple and
neat, but I was thinking that maybe you could avoid the first loop, by just
adding an else to the main if in the second loop. Not sure if it'll make a
noticeable difference in performance, since assigning an empty string to an
array element is fast, but you'll be saving almost 100.000 iterations (on a
320 x 300 image).

Something like this:

  comp[0] = orig[0];
  var lastEqualIndex = 0;
  for(var i = 1; i  l; i++){
if(orig[i] != comp[lastEqualIndex]){
  //new color
  comp[i] = orig[i];
  lastEqualIndex = i;
} else {
  comp[i] = ;
}
  }
  return comp;
}

All in all, it's a good and simple solution!

Cheers
Juan Pablo Califano

2008/2/5, Dave Mennenoh [EMAIL PROTECTED]:

 Hi Juan - I don't think it's assigning the string that's slow. It's
 calling
 sendAndLoad that is slow, because I think when you make the call the data
 is
 urlencoded or something. I've already found that, and am not calling it. I
 was simply outputting the before and after string lengths to see how
 Base64
 and LZW worked. Could be the class I was using, but either way it was way
 too slow to be useful to me. My simple array compressor is nearly instant
 and on some images it's getting me an 80%+ reduction in the array size,
 which is more than enough for my needs. On average it's only around a 20%
 or
 so reduction, but that's still good enough as my images are not very big.
 I think you're idea is great, and for AS3 a definite, but in AS2 I fear
 it's
 just going to be too slow. Plus, I've already spent far too long on this
 little aside and should be moving on, though I do enjoy these kinds of
 things. If you want to see some of my test results, I posted a little
 article on my blog: www.dmennenoh.blogspot.com

 Thanks much!


 Dave -
 Head Developer
 http://www.blurredistinction.com
 Adobe Community Expert
 http://www.adobe.com/communities/experts/

 ___
 Flashcoders mailing list
 Flashcoders@chattyfig.figleaf.com
 http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


Re: [Flashcoders] Simple compression algo?

2008-02-04 Thread Dave Mennenoh

Sounds a bit like Run Length Encoding


Right, I mentioned that. :) I kept it simple to be able to reconstruct the 
image from it more easily in PHP. Gotta try the base64 thing next.



Dave -
Head Developer
http://www.blurredistinction.com
Adobe Community Expert
http://www.adobe.com/communities/experts/ 


___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


Re: [Flashcoders] Simple compression algo?

2008-02-04 Thread Juan Pablo Califano
Actually, from my tests (on the component I made, which was AS 3.0), the
bottle neck was not encoding to base 64 per se (as I assumed at first), but
assigning the resulting string to the LoadVars object (o URLRequest in my
case...). If I commented out that specific line, it worked way faster; when
the big string was assigned to the URLRequest, it took a while, even in AS
3.0 (I'm talking about really big images, perhaps some 1 MB string...)

In my component I used a mix of AS 2.0 and AS 3.0. The app was AS 2.0; I
got the raw pixel data and sent it to the AS 3.0 module (loaded in an
invisible frame) through a local connection (in various passes not just
the whole array because there's a limit, I think it's 40 Kb or something
like that).

Once I got the raw pixel data in the AS 3.0 module I converted it to jpeg,
then encoded it to Base64, and the post it to the server. It took a while to
get it right, but finally I got it working. Later I realized that the
URLRequest object lets you send binary data, so I avoided the base64
encoding step.

You're stuck with AS 2.0, so there are things you can't do. For instance,
posting binary data to the server. As far as I know, you just can send text,
using a LoadVars obj.

However, you can try to create the jpeg in the swf. I'm not saying it'll be
faster. Who knows. But maybe it's worth trying. I have a JPGEnconder class,
that can be ported to AS 2.0. The code is far from understandable to me, but
just adapting it to AS 2.0 seems feasible. The only thing missing is the
native ByteArray class, but it's not that hard to make one (in the end, it's
just a storage structure with a pointer / cursor and a few methods to make
it easier reading bytes, shorts, ints, etc).

So, I think the parts needed to give it a try are there. If you're
interested  I can post somewhere the Base64 class (AS 3.0, should be
ported), the ByteArray (might need to add some methods but already
reads/writes unsigned bytes and unsigned shorts), and a Base64 encoder (AS
2.0, too, I've used to some extent and works fine).

What I was thinking, to sum things up, is this:

* get the raw image data into a ByteArray
* encode that data to create a JPEG image in memory
* encode that image data to base64
* post the resulting string to the server

Might or might not cut it, haven't tried it as I said, and that's really the
only way to know.

If you want to use some of the code I mentioned to give it a try, just let
me know.


Cheers
Juan Pablo Califano

2008/2/4, Dave Mennenoh [EMAIL PROTECTED]:

  you're sending a comma separated string to the server?
 
  why not have 2 hey digits for all the data and omit the comma? this
 would
  bring your data to 2/3 of its size, which means 26sec*2/3 = 17.3sec
 
  when this works, you could try to send binary data - so instead if
 sending
  the string ff you would send the binary byte 255. if this works, this
  would cut the time in half again = 8.6sec
 
  if you can't create binary data, you could still use base64 encoding
  instead, which would give you 8.6*1.33 = 11.5sec.

 Yeah, I'm sending an array of colors. What's a hey digit? And it's not FF,
 that was just an example, it's colors so it's FF or 16777215 as an
 integer and it's not any faster to send as integers, in fact I found it a
 little slower so am sending the hex string. Keeping in the commas just
 makes
 it easy to reconstruct the image since if an array index is null I just
 use
 the last good color. I did say it was simple. :) I'll definitely give
 base64
 a shot. I'm stuck with AS2 here so I didn't think I could do binary, but
 Juan seems to say it's possible.

 Thanks

 Dave -
 Head Developer
 http://www.blurredistinction.com
 Adobe Community Expert
 http://www.adobe.com/communities/experts/

 ___
 Flashcoders mailing list
 Flashcoders@chattyfig.figleaf.com
 http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


[Flashcoders] Simple compression algo?

2008-02-03 Thread Dave Mennenoh
Hi all, I've been working on allowing users to dowload a jpeg from a 
movieClip in AS2 and came up with a simple, yet novel compression idea, 
that's a bit like RLE but not quite.


Basically it is this - analyze the image pixel by pixel to get the hex color 
codes into an array. Then, make a new array the same length as the colors 
array, but filled with  - so it's full of nulls. I then iterate the colors 
array and if the current color is the same as the previous color, I don't 
add it to the new array - otherwise I do.


So if I have: [ff, ff, ff, aa, ff, aa, aa, aa, aa] the new array would be 
[ff, , , aa, ff, aa, , , ]


It makes it easy to reconstruct too, and it's taken about 7 seconds off in 
my tests. Saving a 300x320 image went from about 26sec to now 19sec. It's 
not huge, but everything is something...




Dave -
Head Developer
http://www.blurredistinction.com
Adobe Community Expert
http://www.adobe.com/communities/experts/ 


___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


Re: [Flashcoders] Simple compression algo?

2008-02-03 Thread Juan Pablo Califano
Interesting stuff. I assume you're creating the jpeg on the server since you 
seem to be passing the raw bitmap data (compressing the pixel data with your 
algorythm).


Perhaps another approach worth trying is creating the jpef directly on the 
Flash app. Have you tried it?


I've done that with AS 3.0, using a class provided by adobe, JPGEncoder, 
that I found browsing the web. I think it could be easily ported to AS 2.0; 
the only AS 3.0 feature used in the encoder is the ByteArray, which can be 
ported to AS 2.0 as well. I've already done that and it works fine; of 
course, since it's AS and not native code (and since it runs in the AVM1 
instead of the AVM2), the performance would not be as good as the native 
ByteArray. I haven't benchmarked or stress-test it, but so far, it gets the 
job done.


The cons of this approach: it will require more processing on the client 
side (perhaps too much to consider using it in production, but the only way 
to know is testing and benchmarking, I guess). On the other hand, sending a 
~10 - ~15 Kb jpeg upstream should be way faster than posting a ~750 KB 
string (assuming 24 bits per pixel, 300 px * 320 px * 4 bytes (3 per pixel, 
1 for the each comma) * 2 (taking the max value of 'ff', 2 chars). Probably 
it's a bit less than that since your are compressing it...


Can you describe the flow of your app?

Cheers
Juan Pablo Califano

- Original Message - 
From: Dave Mennenoh [EMAIL PROTECTED]

To: Flash Coders List flashcoders@chattyfig.figleaf.com
Sent: Sunday, February 03, 2008 8:12 PM
Subject: [Flashcoders] Simple compression algo?


Hi all, I've been working on allowing users to dowload a jpeg from a 
movieClip in AS2 and came up with a simple, yet novel compression idea, 
that's a bit like RLE but not quite.


Basically it is this - analyze the image pixel by pixel to get the hex 
color codes into an array. Then, make a new array the same length as the 
colors array, but filled with  - so it's full of nulls. I then iterate 
the colors array and if the current color is the same as the previous 
color, I don't add it to the new array - otherwise I do.


So if I have: [ff, ff, ff, aa, ff, aa, aa, aa, aa] the new array would be 
[ff, , , aa, ff, aa, , , ]


It makes it easy to reconstruct too, and it's taken about 7 seconds off in 
my tests. Saving a 300x320 image went from about 26sec to now 19sec. It's 
not huge, but everything is something...




Dave -
Head Developer
http://www.blurredistinction.com
Adobe Community Expert
http://www.adobe.com/communities/experts/
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders 


___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


Re: [Flashcoders] Simple compression algo?

2008-02-03 Thread Glen Pike

Sounds a bit like Run Length Encoding

Dave Mennenoh wrote:
Hi all, I've been working on allowing users to dowload a jpeg from a 
movieClip in AS2 and came up with a simple, yet novel compression 
idea, that's a bit like RLE but not quite.


Basically it is this - analyze the image pixel by pixel to get the hex 
color codes into an array. Then, make a new array the same length as 
the colors array, but filled with  - so it's full of nulls. I then 
iterate the colors array and if the current color is the same as the 
previous color, I don't add it to the new array - otherwise I do.


So if I have: [ff, ff, ff, aa, ff, aa, aa, aa, aa] the new array would 
be [ff, , , aa, ff, aa, , , ]


It makes it easy to reconstruct too, and it's taken about 7 seconds 
off in my tests. Saving a 300x320 image went from about 26sec to now 
19sec. It's not huge, but everything is something...




Dave -
Head Developer
http://www.blurredistinction.com
Adobe Community Expert
http://www.adobe.com/communities/experts/
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders




--

Glen Pike
01736 759321
www.glenpike.co.uk http://www.glenpike.co.uk
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


RE: [Flashcoders] Simple compression algo?

2008-02-03 Thread Claudius Ceteras
Hi,

 Hi all, I've been working on allowing users to dowload a jpeg from a 
 movieClip in AS2 and came up with a simple, yet novel 
 compression idea, 
 that's a bit like RLE but not quite.
 
 Basically it is this - analyze the image pixel by pixel to 
 get the hex color 
 codes into an array. Then, make a new array the same length 
 as the colors 
 array, but filled with  - so it's full of nulls. I then 
 iterate the colors 
 array and if the current color is the same as the previous 
 color, I don't 
 add it to the new array - otherwise I do.
 
 So if I have: [ff, ff, ff, aa, ff, aa, aa, aa, aa] the new 
 array would be 
 [ff, , , aa, ff, aa, , , ]

you're sending a comma separated string to the server?

why not have 2 hey digits for all the data and omit the comma? this would
bring your data to 2/3 of its size, which means 26sec*2/3 = 17.3sec

when this works, you could try to send binary data - so instead if sending
the string ff you would send the binary byte 255. if this works, this
would cut the time in half again = 8.6sec

if you can't create binary data, you could still use base64 encoding
instead, which would give you 8.6*1.33 = 11.5sec.

regards

Claudius

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders