They’re just 256X256 tiles but they take more than 100ms to decode on a 624 mhz processor. I’m sure it could be MUCH faster, but dont’ know where to begin.

Bill

Thanks for the very quick reply! I don’t think it’s a 64/32 bit problem. I have 32 bit int’s, 16 bit short’s and 8 bit char’s, as expected by the code. Thanks anyway. I’ll keep investigating.

Steve

Hmm, I don’t know. At one point I had a similar problem to what you’re describing, where the JPG image started out correct but then got messed up. It was due to the assembly language DCT algorithm being used at the time. Switching to the C code DCT function fixed the problem, and I then wrote an assembly version of that C code to make it run faster. Is there any chance this might be a data type problem (eg you’re running on a 64 bit machine when this code perhaps assumes 32 bits) or something like that?

Good luck!

Frank.

I’ve been trying to build and use this jpeg code in a Microsoft Visual C++ project to convert 24 bit RGB images to JPG. I removed the __attribute__ stuff and switched it back to using all the C routines instead of the assembler ones, but I can’t get it to work properly. It seems to produce a JPEG file in which the first few 8×8 blocks of pixels look correct but the rest of the image is corrupted. On quality level 8 the length of the strip of blocks which look right is longer than it is on quality level 1. I don’t suppose you’d have any idea what I might have got wrong?

The only changes I made to the code were:
Remove the __attribute__s.
In “encodeMCU”, called “quantization” instead of “quantization_asm”.
In “DCT”, commented out the part were it just calls “jpegdct” and returns.
In “huffman”, made it call the PUTBITS macro instead of “putbits_asm”.
In “read_rgb24_format”, I changed the “#if 0″s to “#if 1″s and vice versa, this stopping it using “read_rgb_yuv”.

Any help gratefully accepted!

Thanks

Steve Howell

INT16 *CB_Ptr = CR;//CB;
INT16 *CR_Ptr = CB;//CR;

Next step, the inverted image.

Thanks a lot
Franklin

Chances are the image is inverted because that’s how it comes from the camera. A great many cameras return an inverted image. Not all, but lots.

A BMP image is actually upside down. So if you’re going from a BMP to a JPG, that’s likely what you’re seeing. A BMP stores the image inverted. So if the image comes from the camera inverted & is stored in a BMP “as-is”, the BMP viewer will invert it, resulting in a right-way-up image when viewing the BMP. But a JPG file stores the image as-is, so an inverted source image will result in an inverted JPG image.

RGB24 is a somewhat ambiguous thing. Some drivers think the byte order is red – green – blue. Other drivers think it’s blue- green – red. I’ve seen both. In either case green will be correct, but sometimes red & blue will be swapped.

This can easily be seen by pointing the camera at a strongly-coloured red & blue object. If the colours display backwards, you know where the problem is.

A blue cast (or any other colour cast) over the image may also be caused by a wrong (or completely missing) white balance algorithm. Artificial lighting can also cause a colour cast (our eyes/brains are remarkably good at ignoring such things) – try changing the lighting a bit.

Have fun!

Just some quick feedback: FOUR_ZERO_ZERO works, too. Tested it with a monochrome cam.

Greetings!