Home > Archive > Compression > March 2007 > How long it takes to code still image using JPEG ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How long it takes to code still image using JPEG ?
|
|
| oshaban 2007-03-28, 6:56 pm |
| Hi ...
I did my own code form a to z using DCT JPEG algorithm using Huffman
code.
I used the DCT as 2D formula ... so the code is not optimized yet.
I run Lena 512x512 pixel (Grey) ... The run time for the coder is 19
seconds !
It is too much as I think. Would you please tell me what is the range
of time for processing such an image?
The answer is too important for me.
Thanks
| |
| oshaban 2007-03-28, 6:56 pm |
| I forgot to mention that my computer processor is 1.7 GHz, 512 MB of
Ram.
| |
| cr88192 2007-03-29, 3:56 am |
|
"oshaban" <shabano@gmail.com> wrote in message
news:1175082635.031097.137330@n59g2000hsh.googlegroups.com...
> Hi ...
> I did my own code form a to z using DCT JPEG algorithm using Huffman
> code.
> I used the DCT as 2D formula ... so the code is not optimized yet.
> I run Lena 512x512 pixel (Grey) ... The run time for the coder is 19
> seconds !
> It is too much as I think. Would you please tell me what is the range
> of time for processing such an image?
> The answer is too important for me.
> Thanks
>
not to worry.
you can optimize the DCT far beyond what might be easily imagined.
for example, in a project of mine, I was encoding jpegs at 320x240, every
1/15 second, without notably degrading framerate in a 3D renderer/modeler of
mine (I had then discovered that it was neither the scaling nor encoding
that was hurting my framerate, but that for whatever reason glReadPixels is
damn slow...).
so, tips for huffman:
do not encode a single bit at a time, rather, implement the encoder such
that a whole symbol is encoded at a time (ie, via indexing a table, doing a
shift and an or to add this to a temporary window, and possibly outputting
some bytes if the window is sufficiently full);
the deflate spec (RFC1951) may give a few useful pieces of info wrt this.
and, wrt dct:
do it as 2 1D dct passes, for example, horizontal then vertical;
note that one can get some speed by precomputing all these values
(eliminating all these computations and cosines);
note that one can get more speed by converting this to fixed point;
even more gain is possible by inlining all the values into large equations,
and then factoring out the reusable parts.
so, yes, if done write, jpeg encoding can be fairly quick, and if done
poorly it can be rather slow...
|
|
|
|
|