Comments on: Performance

By: tihopilik

tihopilik — Mon, 09 Jul 2007 08:18:31 +0000

I can’t be bothered with anything these days, but shrug. I just don’t have anything to say recently.

G’night

By: schani

schani — Mon, 02 Jul 2007 07:16:29 +0000

Thanks for all the helpful comments Itai and everybody else! As soon as I have time again I’ll try to improve my C# version of the image processing and put it into the application.

By: Itai Bar-Haim

Itai Bar-Haim — Sun, 01 Jul 2007 21:01:40 +0000

Hi again, sorry for the separate post, just wanted to share my results.
The overall gain on my computer for a 4MP photo (2304×1728) is about 15% (from 64.8125 seconds to 56.53125 seconds), using the techniques I described in my two posts above.

Itai.

By: Itai Bar-Haim

Itai Bar-Haim — Sun, 01 Jul 2007 20:53:08 +0000

I managed to reduce time by (1) eliminating the helper-counters rowIndex and rowMaskIndex, and instead of recalculating index and maskIndex each loop, I just add 3 to index and 1 to maskIndex at the end of the most inner loop. Works great with what I suggested in my previous post. In addition, I eliminated the ir, ig and ib variables and placed the inData access directly in the sgray computation line.
In the outData lines, I put the last part of each line (which is the same in all lines) in a variable, and used it instead. In addition, this line is using (65535 - inverted), which is actually *contrasted*, so just used it instead (resulted in a noticeable gain).
I converted the layers loop to a foreach loop. didn’t help, didn’t hurt anything, and looks nicer.
I placed the declaration of sgray outside the loops (only the ‘int sgray;’). It helped a bit.

Hope this helps.
Itai.

By: Itai Bar-Haim

Itai Bar-Haim — Sun, 01 Jul 2007 19:15:07 +0000

It seemed I got some increase in speed when I didn’t perform arithmetics to define index position in the array. Instead I accessed inData directly with index, putting the ib first, then performed ++index while accessing inData for ig, then again for ir, and the opposite order for outData. Optimizations where on, unsafe code allowed and used (wrapping the inData and outData access parts). My system is really old and slow (P4 1.7gh, 512MB ram)

Hope it helps a bit.
Itai.

By: thefoxisonfire

thefoxisonfire — Sun, 01 Jul 2007 13:30:20 +0000

Ok that is understandable, however then you still only need 2 copies (8 bit source and 16 bit working copy).

You have:
1 copy (new Bitmap)
1 copy (values array)
1 copy (inData array * 2)
1 copy (outData array * 2)
1 copy (newValues array * 2)
and you would have
1 copy more if you didn’t overwrite your sourceimage in the end
and
2 copys (masks, did not count these anyways, are per pixel, not per color)

If you load a single 16 Megapixel photo you app needs about 400MB RAM just for data.

You could make the app about 10 times faster than it is now. There are more than enough suggestions in your comments. If you don’t want to nobody is going to force you ;)

By: schani

schani — Sun, 01 Jul 2007 07:18:56 +0000

Well, the point is to do 16 bit processing from start to finish, i.e. to be able to process 16 bit source images and save the result as 16 bit images, so I don’t want to have anything to do with 8 bit images in my processing core. I’m loading the 8 bit image simply to have some image to work on.

And I don’t think that I hold each pixel 6 times.

By: thefoxisonfire

thefoxisonfire — Sat, 30 Jun 2007 21:52:59 +0000

I’ve seen that. But it seems to me that you only do per-pixel processing so there is no need to keep the entire dataset but only the data for a single pixel. And in fact you hold each pixel multiple (6?) times.
The library I mentioned does most calculations in double precision, however as soon as the data is saved out its still only a 32bpp image (8bits per channel).

By: schani

schani — Sat, 30 Jun 2007 18:48:19 +0000

I’m reading the data in as 3×8 bit but I’m converting it to 3×16 bit because I want the engine to do 16 bit image processing.

By: Top Posts « WordPress.com

Top Posts « WordPress.com — Sat, 30 Jun 2007 00:01:31 +0000

[...] Performance I have three implementations of the B&W image processing core now. One of them uses GEGL, another one is written in C# […] [...]