|
From: | David Grundberg |
Subject: | Re: reading jpegs faster |
Date: | Fri, 22 Jan 2010 15:39:51 +0100 |
User-agent: | Thunderbird 2.0.0.23 (X11/20090812) |
John W. Eaton wrote:
On 22-Jan-2010, David Grundberg wrote:| I'm reading 10 megapixel jpeg files alot. Unfortunately it me takes 9 | seconds to load such files with imread on the tip. I think that is too | long time. Is someone experiencing the same problem as me? Or does it | have to do with my configuration? | | I've written a function file in C++ that loads the same file in about 1 | second.Doesn't the GraphicsMagick library ultimately use libjpeg? What causes it to be slow? Rather than writing a special case for jpeg files, I think it would be better to find out why imread is slow and fix that. It's possible that would improve the performance of Octave's imread function for all image formats, not just jpeg files. jwe
I would guess it the slowness is due to extra copying/conversion being done. For example, for (int y = 0; y < rows; y++) { idx(0) = y; for (int x = 0; x < columns; x++) { idx(1) = x; idx(2) = 0; im(idx) = scale_quantum_to_depth (pix[i].red, depth); idx(2) = 1; im(idx) = scale_quantum_to_depth (pix[i].green, depth); idx(2) = 2; im(idx) = scale_quantum_to_depth (pix[i].blue, depth); i++; } }is slow and stands for the most of the time spent. I think it's a good idea to use a general-purpose library like GraphicsMagick++, but as it currently stands it's wasting a lot of cycles just converting between char, int and double, and modifying index vectors. And the end result is that we've converted uint8 to uint8. I did some ugly hacks to the above loop but I wasn't particularly successful; got down to disappointing 6 seconds.
There's also the problem with the Octave image convention, a backwards way of storing images, where pixels are scattered throughout memory. Maybe the postprocessing to Octave image conventions could be done with more general purpose tools like Array::permute? Or is the current approach with rearranging directly better?
GraphicsMagick++ way of representing pixels (PixelPacket *), a blessing or a curse? It is a catch-all representation that will make conversions obligatory where there would be an opportunity to use data directly.
David
[Prev in Thread] | Current Thread | [Next in Thread] |