[Insight-users] co-occurrence matrix

[Luis Ibanez]

Hi Zach,


0) There is no fundamental reason for wanting to have the explicit
    list of samples. In fact, avoiding to have that list is the most
    compelling justification for implementing this class as an Adaptor
    instead of a filter.

    The Adaptor simply "makes" the source image look like a list of
    samples but without incurring in the explicit construction of
    such a list. This should save both memory and computing time.


    Your suggestion of writing directly a HistogramGenerator is also
    a good option since it actually solved the full problem from the
    user point of view. The only issue is that you may want to avoid
    replicating code that already exist in the ListSampleToHistorgram
    Generator. In that regard is more consistent for the toolkit to
    have the CoocurrenceMatrix implemented just as an Adaptor.


1) Knowing that the Adaptor is intended to be used by an Histogram
    calculator, we only need to provide a sequential-like access to
    the fictitious list of samples. Using only iterators is an acceptable
    solution and follows better the ideal of decoupling between
    containers and algorithms applied over containers. This is what
    has been done in STL, for example.


A good approach is to look at the code of the
itk::ListSampleToHistogramGenerator in order to get an idea of
the methods that this class uses from the itk::ListSample class.
You only need to implement those methods in the CoocurrentMatrixAdaptor.

Note that the fact that ListSampleToHistogramGenerator is templated
over the ListSampleType is what makes possible to trick it and make
it work over any other class that satisfies a specific subset of the
ListSampleType API.


Please let us know if you have any other questions,


   Thanks


      Luis


----------------------
Zachary Pincus wrote:

> 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
>>
> 
>