I've noticed that the first call to Magick::Image::pixelColor(...) is painfully slow.
Image i(Geometry(12000, 10000), Color(0, QuantumRange, 0)); // allocate image = slow
i.pixelColor(1, 1, Color(QuantumRange, 0, 0)); // very, very slow
i.pixelColor(9000, 7000, Color(QuantumRange, 0, 0)); // fast
To be fair, I am working with a large images. The first call must be creating some kind of pixel cache. I see no reason for this. Worse, the pixel cache must overflow memory because this allocation takes far longer than the original.
Interestingly, the following achieves the same result very quickly.
Image i(Geometry(12000, 10000), Color(0, QuantumRange, 0)); // create image = slow
PixelPacket * i_cache = i.getPixels(0, 0, i.columns(), i.rows()); // all pixels, fast
*(i_cache + 1 * i.rows() + 1) = Color(QuantumRange, 0, 0); // fast
*(i_cache + 7000 * i.rows() + 9000) = Color(QuantumRange, 0, 0); // fast
i.syncPixels(); // fast
No question here as I found my solution, just an observation that may help others.
ImageMagick 6.4.2
Magick++
Windows XP
-Chris
pixelColor() is slow
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: pixelColor() is slow
The 'cache' method is vital to the working of IM in a multi-threaded environment, though yes it can be a bit 'heavy'.
Perhaps you like to publish your solution, for those others
Perhaps you like to publish your solution, for those others
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
Re: pixelColor() is slow
Sorry if I wasn't clear. The second chuck of code that utilized getPixels(...) instead of pixelColor(...) was my solution as it was very quick.
-Chris
-Chris