|
Re: GIF Image Processing
by dws (Chancellor) on Jan 22, 2002 at 01:57 UTC
|
I want to process to detect edges without decompressing the image first.
You want to detect edges before you decompress the image? Are you sure? Most edge detection algorithms depends on having a matrix of pixels. That implies decompression.
If you don't want to decompress all at once, you'll at least have to do some sort of banding algorithm to get an uncompressed band of scanlines, with enough scanlines to do incremental edge detection on. I've not heard of anyone having done this, but GIF decompression algorithm certainly makes this possible.
Unless you're under really tight space constraints, you'll get there a lot quicker if you decompress first.
| [reply] |
|
|
To asnwer your question - yes, I want to detect edges without decompression. I realize that this is not going to be very accurate. However, I'm not going for accurasy, I'm going for crude functionality and SPEED.I have done research in the past, and I know that detection without decompression is possible for JPEGs (see here) JPEGs are much more involved in encoding. If it's possible to do edge detection with JPEGs, I only assume that it is also possible to do it with GIFs since that encoding algorithm is MUCH simpler.
| [reply] |
|
|
Jpegs are in my understanding, store rectangular sections of the image ( If I remember stored coefficients), so I guess you could do edge detection as the compressed data represents some sort of semblance to what is encoded, but
GIF's are just LWZ encoded chunks. I don't see any way you could determine what's in it without decompressing.
-Lee
"To be civilized is to deny one's nature."
| [reply] |
Re: GIF Image Processing
by talexb (Chancellor) on Jan 22, 2002 at 00:56 UTC
|
Edge detection is a somewhat complicated process, and to do it without decompressing the image first sounds like an insane task. Don Quixote comes to mind. :)
--t. alex
"Of course, you realize that this means war." -- Bugs Bunny.
| [reply] |
Re: GIF Image Processing
by simon.proctor (Vicar) on Jan 26, 2002 at 03:04 UTC
|
Please correct me if I'm wrong (it happens all the time) but GIF images are not compressed as such, instead they use an index map into a pallette of colours. I would have thought, then, that you can apply your image detection algorithm on the matrix of indices.
Update:Thanks to dws :). I forgot all about the Unisys patent and the compression algorithm wrangles.
I don't have my notes anymore but I did something similar on a raw binary file at University. Essentially the algorithm worked by taking a group ok3x3 matrices and applying them successively to a set of data. Depending on the final result, it recorded a 1 (an edge) or a 0.
My gut feeling is that you may not be able to get away without first changing the indices for the actual binary values. However, thats just a hunch :)
I still have the code somewhere but its in OCCAM and is designed to run on a transputer network so I don't know how useful it may be to you. | [reply] |
|
|
Please correct me if I'm wrong (it happens all the time) but GIF images are not compressed as such, instead they use an index map into a pallette of colours.
GIF uses the Lempel-Ziv-Welch (LZW) compression algorithm, for which Unisys has a patent. There's a reasonably good explanation of the compression scheme here.
Once uncompressed, you get a matrix of indices into a color palette.
| [reply] |
|
|
You are correct in your statement - GIFs do use LZW compression. However, ideally I want to use an image to detect its edges in as few clock cycles as possible. I thouhgt that if "decompression" was skipped, then I could achieve this goal (or at least come to a rough approximation of the edges).
| [reply] |
|
|
|
|
|
|
I would be ver interested in some more details of that algorithm. Can you please post them or email them if you still remember it
| [reply] |