Having methods of explicitly choosing the layout, or matching the =
layout of an existing image, does seem to be useful.
I also agree that it would be pragmatic to concentrate on a few common =
We could have an enum type vil_image_layout:
vil_layout_pji, vil_layout_ijp, vil_layout_other(and possibly =
then have set_size(ni,nj,np,layout), as well as a constructor.
Does anyone have an estimate of the cost (in time) of cache misses when =
processing a [j][i][plane] image with an algorithm designed for =
I can see that it would be useful to have different variants of =
on the layout, to minimise such problems (in a few algorithms that is =
already the case).
Tim Cootes Professor of Computer Vision
Imaging Science and Biomedical Engineering tel (+44) 0161 275 5146
The University of Manchester fax (+44) 0161 275 5145
Manchester M13 9PT , UK mailto:t.cootes@...
From: vxl-maintainers-bounces@... on behalf of Amitha =
Sent: Thu 11/1/2007 4:31 AM
To: Ian Scott
Subject: Re: [Vxl-maintainers] [Vxl-users] vil_resample_bilin =
andplanestep() !=3D 1
On Wed 31 Oct 2007, Ian Scott wrote:
> I'm a little worried about any cost overheads this might impose.=20
> Typically the image processing functions iterate as
> for(p...) for(j...) for (i...) so the cache miss costs in a different=20
> default layout could be significant. I guess these would only be paid =
> people who pass in [j][i][plane] images.
Which, I think, is quite a few people, but that's neither here nor
there. When writing the loops, one has to pick one ordering, and thus
will disenfranchise the other five. Since vil loops are written for
the [p][j][i] order, users who have the luxury will chose that order,
and all will be well with the cache. Otherwise, images will tend to
preserve the input layout, which is the most intuitive behaviour.
Those who want more complex behaviours will have to appropriately
resize/allocate the destination image, ensuring that the set_size is a
> It seems to me that we need to be careful defining which aspects of =
> layout we want to preserve. Is it just the two special cases
> [j][i][plane] and [plane][j][i], or should we preserve all possible=20
> layouts? Note that all possible layouts includes non-compact ones.=20
> Whilst some of the least compact layouts (for example as produced by=20
> vil_decimate) are probably bad to preserve, there are some =
> for preserving word-aligned rgb triplets, or aligned raster starts. =
> costs for checking for and constructing all possible interesting =
> are not straight forward.
I agree. I side on just preserving plane vs component layout. More
complex choices can be left to the user, by asking the caller to
preallocate the destination.
The concept of a layout encoding (which I haven't quoted from your
message) is interesting. Although you referred to a couple of
layouts, the fundamental assumption is that we can enumerate a few
special types of layouts that will be preserved where possible on the
destination image of vil functions. In general, these will be the
"packed" formats. But alignment can extend to pixels, or to
components, to lines, etc. That is, each of pstep, istep, and jstep
can have it's own alignment requirements. (E.g. RGB 3-byte pixels
aligned on 4-byte boundaries, with each line aligned on 8-byte
boundaries.) The discussion of whether this would be useful should
perhaps move to another thread.
However, note that even if we have these alignment and layout options,
dest.set_size( src )
could capture all of it.
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Vxl-maintainers mailing list