Hi Friends
I have a question ,I am trying  to write a program with assembly language that I can print a jpg file .
PLEASE HELP
Posted on 2012-01-01 08:18:43 by sunny
The first easy task is to load the jpg file into memory.
You then have to decompress that file and convert it into a Bitmap file. You can either write your own converter (very interesting and demanding) or import someone else's algo based on the OS you are using.
Finally, you tell the OS to print it.
Posted on 2012-01-01 23:07:08 by Raymond
This looks like it might contain some valuable information:

http://www.fileformat.info/format/jpeg/egff.htm

In the JPEG section of chapter 9 (compression methods), it suggests that this is not something you can knock off in a few evenings, and that you will probably want to use a 3rd party library instead... (as Raymond suggests). Doing this in assembly language shouldn't present a big problem, but there isn't much advantage to doing it in asm, either... sadly...

Best,
Frank

Posted on 2012-01-02 17:17:48 by fbkotler
thanks  a lot :D
Posted on 2012-01-18 11:53:02 by sunny
but there isn't much advantage to doing it in asm


I may agree, but only if you consider that a 4X speedup isn't much of an advantage. Such can be achieved by doing some of the computations with MMX instructions which may not be available through HLLs.
Posted on 2012-01-18 21:32:21 by Raymond
Hi Raymond,

I think you may have taken me out-of-context...


... and that you will probably want to use a 3rd party library instead...


Thats what I was saying that there isn't much advantage to doing it in asm. Sorry if I wasn't clearer. You aren't saying you can get a 4X speedup by calling a 3rd party library from asm vs HLL... are you?

If I haven't thanked you for that FPU tutorial, Thanks. If I have, Thanks again. I don't suppose you've got one on using MMX to decompress JPEGs? :)

Best,
Frank

Posted on 2012-01-18 22:52:42 by fbkotler
you've got one on using MMX to decompress JPEGs?


I did write one a few years ago (as a personal challenge). The cosine transform is the bottleneck in that decompression. I then looked into MMX instructions for curiosity and was surprised at the speed improvement a few instructions made for such an application.

FYI, that was the first and last time I looked into MMX; don't expect any expertise from me on that subject. :)
Posted on 2012-01-18 23:32:06 by Raymond

I did write one a few years ago (as a personal challenge). The cosine transform is the bottleneck in that decompression.


It is, but only after you've optimized the huffman decoding phase :P
I've written a JPG decoder myself... and one time a friend of mine had a Canon camera on which you can run homebrew software. It had an 80186-compatible CPU and ran ROMDOS.
He found this open source application that could calculate the histogram of a picture. A feature normally only found on the more expensive models.
Problem was: it was very slow. Took about 9-10 seconds to do the histogram.
So at first my friend started optimizing the histogram calculation and drawing code itself, and he could get it down to about 6 seconds.

At that point, the picture decoding was the bottleneck. It basically decoded the luminance (Y-channel) of the thumbnail in the picture (which is stored as a JPG inside a JPG). So he asked me to look at the JPG code, to see if it could be optimized.
As it turned out, the Huffman was not a very efficient implementation. It iterated through the values in some way (don't recall the exact details).
The decoder I had designed, precalced some bruteforce LUTs, after which code lookups were pretty much O(1). So we plugged that decoder in... and the time went down to about 2-3 seconds.
So yea, NOW the iDCT was the bottleneck. I believe the original code was actually based on the Independent JPEG group reference implementation... so perhaps the Huffman performance issues are present in that one as well.
Posted on 2012-01-19 06:38:32 by Scali
Hehe, bottlenecks, first you find it, then you squash it, then it moves somewhere else.
There is no way to eliminate them :P
I'm not an MMX expert either but I've written workable MMX code, and can probably add value to discussions involving MMX/SSE stuff.
Scali was right when he said that premature optimization is the root of all evil.
First, identify the bottleneck, then worry about how to deal with it.

Posted on 2012-01-20 03:05:56 by Homer