Hey Patrick,

Honestly, since you have to store your images somehow, and most file formats store the pixels together, you are going to have to pay the cost of unwrapping the channels at some point. If you are doing a lot of manipulations in sequence, it makes sense to do it early on in your pipeline — but at that point it might make the most sense to unwrap the channels altogether into separate grayscale images, getting both speed and compatibility, at the cost of perhaps some readability.

Another option would be to just use column-major order for all your images. Although it's not the default, Numpy provides for this (`order='F'`). I think all of our functions and Numpy's would work out of the box, and you'd get your performance boost! Come to think of it, that might be the magic you were looking for! =P

Juan.


On Thu, Jul 17, 2014 at 4:33 AM, Patrick Snape <patricksnape@gmail.com> wrote:
Hi Juan,

Thanks for getting back to my lengthy post!

I assumed that it was convention. As you said, we originally followed this scheme when we moved from Matlab and have only recently realised that it makes complete sense for Matlab to have that format, but not for us. It's also true that packages such as PIL return images in that format (presumably to maintain consistency with file formats, as you mentioned).

I agree that it makes more sense from a notational perspective, however, channels first allows you to do really nice things like:

for channel in image:
    channel[i, j]

which I like a lot.

My follow up was merely going to be more of a comment that a question to be honest. I just wanted to make sure I wasn't missing a trick somewhere whereby all my woes could be fixed via some magic I had failed to see. In our package, we implement a lot of image alignment methodologies and thus computations like the gradient etc are more important to us than treating channels as related features. We are very interested in algorithms like HOG, DSIFT, LBP that treat all the channels separately, so I'm seriously considering flipping our image type to get the performance boost.

It's just that I also dislike the idea of losing our current simple compatibility with scikit-image!

I will think hard on it. Thanks again for the reply!