[Insight-developers] SimpleITK R Wrapping

[Bradley Lowekamp]

Hello,


On Feb 1, 2012, at 6:46 PM, Richard Beare wrote:

> I'll look into the ToString option.
> 
> I have a question - is there a method that provides mapping between
> PixelValueID and the string that gets used in the accessor functions -
> GetPixelValueAsUInt8 etc, or at least the UInt8 part?

No, there currently not such a method. There is one that converts it to a user readable string, but not to a string of the enum used for the ID. Is certainly could be added to teh sitkPixelIDValues.h file.


Please be aware that SimpleITK has been designed with the idea that the PixelID values may change based on configurations. So you should first check that the enum is not -1, which indicates that the type is not supported. 

> 
> I'm not quite sure what you mean by the second part. The code I've
> added to deal with vectors currently does the following (note that
> part is a replacement of the auto generated code that seems to be
> incomplete):
> 
> 1) Ties these types into the standard R display mechanisms (print and show)
> 2) Provides the standard R bracket operator for access and assignment.
> The swig code did the latter, but wasn't quite complete.

So lets talk about the sitk::Image::GetSpacing method. In R it currently returns an object which is a swig wrapper for a std::vector class. Your work has been to enhance this class, while this is useful in the short term. I don't think it should be the goal.

I think the sitk::Image::GetSpacing method should directly return a R array object. So with some swig magic, in needs to be converted to the R object in the C++ code. For example in python this method returns a tuple not a wrapper to std::vector.

> 
> However, what you can't currently do is pass an R vector to one of the
> swig functions and have it converted transparently
> 
>> testim$SetSpacing(testim, b)
> ungraceful crash

I think the same SWIG mechanism that converts the vector->R array can be used to go the other direction. 


> 
> 
> I'm not sure how easy it is to get the binding layer to support R
> objects directly. If it is hard then a lot of the pain of using the R
> interface can be reduced by overloading the built in operators and
> providing some helper functions to create the c++ objects when new
> ones are needed.

Yes, it may be a bit of a challenge to get the native R support I am suggesting ideally.

Brad

========================================================
Bradley Lowekamp  
Medical Science and Computing for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20120202/9b385121/attachment-0001.htm>