Presumably one way we could do this would be to take your code, then add a downsample from the YUV in memory(two steps) and cut two new jpegs ? Another way could be to do something with the JPEG at ain interim stage – but my guess is that gets tricky (e.g. is there an easyish way to transform a 2×2 set of DCTs to a single DCT at some point in the encode – then send that to be packed up into a new 1/4 size JPeg – is there a way at the end to take a Jpeg and reduce by 1/2 x 1/2 without decoding) . Just musing – will post back if we find anything

Thanks
Jim

Regards,

André

static __inline__ void putbyte(huf_ctx *hc, UINT8 data)
{
*hc->out = data;
hc->out++;
if (data != 0xff)
return;
*hc->out = 0;
hc->out++;
}

static __inline__ void putbits(huf_ctx *hc, int numbits, UINT32 data)
{
int bits_in_next_word;

bits_in_next_word = (hc->bitindex + numbits – sizeof(huf_type)*8);
if (bits_in_next_word lcode = (hc->lcode <bitindex += numbits;
}
else
{
hc->lcode = (hc->lcode <bitindex)) | (data >> bits_in_next_word);
switch (sizeof(huf_type))
{
case 8:
putbyte(hc, hc->lcode >> 56);
putbyte(hc, hc->lcode >> 48);
putbyte(hc, hc->lcode >> 40);
putbyte(hc, hc->lcode >> 32);
case 4:
putbyte(hc, hc->lcode >> 24);
putbyte(hc, hc->lcode >> 16);
case 2:
putbyte(hc, hc->lcode >> 8);
putbyte(hc, hc->lcode);
}
hc->lcode = data;
hc->bitindex = bits_in_next_word;
}
}

I just wanted to thank you for this implementation. I’m using it on an i486 800MHz SBC, with uClibc and a highly modified version of Palantir. With your code (modified for my needs and ported to C++), Palantir went from 13.25fps to 25.25fps! An absolutely incredible increase in speed!

Martin

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