Re: Slow converting index color to RGB
Re: Slow converting index color to RGB
- Subject: Re: Slow converting index color to RGB
- From: "Alastair J.Houghton" <email@hidden>
- Date: Wed, 27 Aug 2003 11:20:04 +0100
On Wednesday, August 27, 2003, at 04:47 am, Lance Pysher wrote:
Why is this so slow?
[snip]
while (i < [[[self dicomObject]
objectWithDescription:@"PixelData"] length]){
*pointer++ = red[(unsigned char)*pixelData];
*pointer++ = green[(unsigned char)*pixelData];
*pointer++ = blue[(unsigned char)*pixelData++];
i++;
}
[snip]
This loop calls four methods per iteration. How about doing
unsigned length = [[[self dicomObject]
objectWithDescription:@"PixelData"] length];
while (i < length) {
instead?
Or even better, get rid of i and do something like
unsigned char *ptrend = pointer + 3 * [[[self dicomObject]
objectWithDescription:@"PixelData"] length];
while (pointer < ptrend) {
There are other things you could do to make it run even quicker; for
example, if you use RGBA rather than plain RGB, then you could build
the pixel data in a register and write it all in one go... e.g.
unsigned long *ptr = [self bitmapData];
unsigned long *ptrend = ptr + [[[self dicomObject]
objectWithDescription:@"PixelData"] length];
while (ptr < ptrend) {
unsigned char data = *pixelData++;
*ptr++ = (red[data] << 24) | (green[data] << 16) | (blue[data] << 8);
}
(You'd need to test that to make sure it went faster, but I expect it
probably does. You'd also need to check the RGB ordering.)
Unrolling the loop (by hand) might be an option as well, although you
could ask the compiler to do it for you with the -funroll-loops option.
If you can guarantee, for example, that you DICOM image is e.g. a
multiple of four pixels in size, you could do four pixels per loop.
Replacing the tables with Altivec computation might speed you up as
well, especially if all three tables are the same. The tables are
quite big --- at 64KB each, they don't fit in the L1 processor cache on
a G4, although they will fit into the L2 cache --- so it'd be worth
experimenting with computing them on the fly; having said that, I
suppose X-Ray images (that's what DICOM's for, right?) don't very in
intensity very quickly so it may not actually be an issue. It's
certainly worth using the CHUD tools to take a look if you want your
code to really fly.
Finally, how about using the profiler (gprof), the CHUD tools (which
are excellent), and/or Apple's Sampler application?
Kind regards,
Alastair.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.