Sending image data (quickly)

Started by
1 comment, last by XXX_Andrew_XXX 19 years, 6 months ago
Hi, I am now sending image data through socket communication however it is too slow. I implemented some basic compressions (reduction of number of bits per color, etc.) but that is not enough. What other options do I have? I was thinking about compressing the data into jpeg format before sending it, but since I am sending an image stream (>15 images/sec if possible), the jpeg compression might slow me even more down. What can you recommend? Thanks :)
Advertisement
Take a look at streaming video technologies (Windows Media, Real Video, Quicktime etc) - they've already got some of the world's top brains looking at the best ways to stream image data over networks...

...the fact that they're animating the frames and you're not shouldn't matter. Though frame to frame coherence is where some of their compression comes from - so if each of your images is very different, you won't be get near their promised rates.

At very least, knowing the maximum rate something like WMV/ASX can transmit a video only stream at will give you an upper bound to aim for with your own technology (if you don't want to use off the shelf stuff).


In terms of compression:

- which "standard" image compression scheme is best depends on exactly what each image contains. For photographs, JPEG will likely be best, but don't blindly use that and expect it to be best for all image types - for hand drawn cartoons or things like faxes there are better methods.

- whether JPEG compression will be too slow depends on what CPU your target hardware contains, and what the speed of your socket connection is. You'll have to look at the figures for your target hardware and see if JPEG encoding is going to be (on average) slower than sending the data byte-for-byte - there isn't a yes/no answer to that question - if you're on a fast LAN with a slow CPU, then maybe sending the data raw is better, in other cases maybe not...

- if this is for a custom system, have you considered a hardware MPEG encoder?

- if the images are computer generated (including artwork drawn on a computer) rather than being sampled/scanned from a real world source, then take a look at the filtering schemes contained in PNG - combine that with the traditional streaming ZLIB stuff or even just RLE.

Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site

I Agree with S1CA that it is going to depend alot on what type of data you're going to be transmitting. One of the biggest issue is going to be working out what losses are acceptable, for example you haven't mentioned anything about the acceptable latency (total time to arrive) for an image.

AFAIK jpeg compression is based on the Discrete Cosine Transformation (DCT) so compression time will depend on both the original image size and the block size (desired compression). It will be a trade-off of higher compression vs longer compression time - testing may show an optimal set of conditions for your application. I'd certainly recommend at least profiling the use a simple jpeg library (both for compression ratio and time), even if all it does is give you a better feel for what is acceptable output with respect to your images. As with most time sensitive programming try to avoid file accesses (keep everything in memory).

If this sounds like to much work you might want to start by subsampling the image (every 2nd of 3rd pixel), but most compression systems (jpeg) use some type of DCT which will probably give better results.



References on DCT

http://www.acm.org/crossroads/xrds6-3/sahaimgcoding.html

http://www.cs.cf.ac.uk/Dave/Multimedia/node231.html

This topic is closed to new replies.

Advertisement