[Insight-users] co-occurrence matrix

[Zachary Pincus]

Hello,

Now that my courses and TA duties are finished for the quarter, I've 
finally had a chance to start work on the co-occurence list adapter 
(and associated classes to make a texture description calculator).

I've got a couple questions about the adapter interface, before I get 
too far into this all:

(0) Is there any compelling reason to provide a list sample interface 
to image intensity co-occurence data? Most uses that I can think of 
involve working with a histogram directly. Because of the issues below, 
and some others, it would seem much easier to simply generate a 
histogram from an image in one step, instead of going through a list 
sample adapter. Do any crucial ITK statistics methods require lists, 
making a list sample adapter class more useful than a histogram 
generator?

(1) If the answer to the above is that it is important to generate a 
list, there are a few issues to deal with.

The list sample interface in general specifies that elements of a list 
should be retrievable by iteration, or random-access through an 
identifier number and the GetMeasurementVector method. The 
ImageToListAdapter deals with this by treating the ID as an index into 
the image pixels.

However, the situation would not be nearly as natural with an adapter 
for creating a coocurrence list. First, the cooccurrence list would be 
ideally defined over a requested region, not necessarily a full image, 
so identifier numbers would need to be converted into offsets into the 
region manually. Second, the co-occurence list uses shaped neighborhood 
iterators, and re-initializing these at each point seems wasteful. 
There are other problems with having multiple offsets per pixel 
location, too.

Ideally, it would be good to only present an iterator interface from 
the list adapter, and not expose the random-access 
GetMeasurementVector(const InstanceIdentifier &id) API. Is this an 
acceptable limitation?

Thanks for your thoughts,

Zach


On May 18, 2004, at 8:27 AM, Luis Ibanez wrote:

>
> Hi Glenn, Zach,
>
> It will be more efficient to implement this class as
> a real Image to List adaptor.  Right now it is more
> like a ImageToList filter since it is creating a list
> and filling it in.
>
> The entire set of pixel pairs gets stored in memory
> this way...
>
> Looking at this, the class should probably not derive
> from the ImageToListAdaptor but rather be an independednt
> ImageToList filter.
>
> ---
>
> My suggestion will be to reorganize this class and make
> it an Adaptor. For this we simply have to move the preparation
> code into a "Initialize()" method, and then open the while
> loop where you are visiting all the pixels and their neighbors.
>
> This loop should be exposed in the method:
>
>  inline virtual const MeasurementVectorType &
>     GetMeasurementVector(const InstanceIdentifier &id) const;
>
> What this method will now do is to return one by one
> the pairs of values from the neighbors. A look at the
> itk::ImageToListAdaptor may help to clarify the use of
> this method.
>
> The List to Histogram generator will then be able to use
> this adaptor directly without you having to pay for the
> extra memory storage for all the pixel pairs.
>
>
> Please let us know if you need help in reorganizing
> this code.
>
>
>   Thanks
>
>
>      Luis
>
>
> --------------------
> Glenn Pierce wrote:
>
>> On Sun, 2004-05-16 at 13:22 -0700, Zachary Pincus wrote:
>>>> In my code I was storing each pair in it's own MeasurementVector. 
>>>> However I should have
>>>> been increasing the frequency for pairs that are the same. Was this 
>>>> changed ?
>>>
>>> Would it be better to store a histogram instead of a list? That way 
>>> the incrementing is done automatically, and one can iterate through 
>>> at (say) 256x256 histogram and directly create a 256x256 
>>> co-occurence image from the bin frequencies. (I assume that's what 
>>> you want, right?)
>>>
>>> I was planning on looking at the code this afternoon to see if a 
>>> histogram might work best...
>>>
>> Yeah that I thought initially.
>> I think I had some trouble implementing it. I can't remember the 
>> problem I was having - sorry.
>> Although I think a 2D histogram would be best.
>> Thanks
>> Glenn
>>> Zach
>>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>
>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>