[Insight-users] AddPixelAccessor set function confusion

[Luis Ibanez]

Hi Robert,

Thanks for reviewing the other pixel accessors.

In those, you have indeed found a collection of bugs.

I have logged a bug entry here:
http://public.kitware.com/Bug/view.php?id=11597


In Summary:

* AbsImageAdaptor (may not be fixable)
* AcosImageAdaptor (fixable - within numerical range)
* AsinImageAdaptor (fixable - within numerical range)
* AtanImageAdaptor (fixable - within numerical range)
* ComplexToImaginary (fixable)
* ComplexToModulus (not fixable)
* ComplexToPhase (not fixable)
* ComplexToReal (fixable)
* CosImageAdaptor (fixable - within numerical range)
* ExpImageAdaptor (fixable - within numerical range)
* ExpNegativeImageAdaptor (fixable - withing numerical range)
* Log10ImageAdaptor (fixable - withig numerical range)
* LogImageAdaptor (fixable - within numerical range)
* RGBToLuminanceAdaptor (possible to trick..)
* SinImageAdaptor (fixable - within numerical range)
* SqrtImageAdaptor (fixable - within numerical range)
* TanImageAdaptor (fixable - within numerical range)


For example, the Trigonometric image Adaptors,
have all the problem that you identified. (e.g.
Sin is computing vcl_sin in both the Set and Get
operators).

These ones could be fixed by using the inverse
trigonometric functions, but with the natural
ambiguity of angles in the circle.

   sin( 150 degrees ) --> sin( 30 degrees )

So SinImageAdaptor should do

   Get(x)  : vcl_sin(x)
   Set(x)  : vcl_asin(x)

Similar partial matches can be solved for

Exp <----> Log

While the case of RGBToLuminance can be
tricked by storing an RGB value that results
in the same luminance.

The ComplexToYYY  are for the most part
not fixable.

More comments follow below...

-------------------------------------------------------
On Fri, Dec 10, 2010 at 2:19 PM, robert tamburo
<robert.tamburo at gmail.com> wrote:
> Thanks for the response Luis. I'm still confused though because none of the
> other pixel accessors use the Set() method for inverse operations,
> e.g., SqrtPixelAccessor, all of the trigonometric accessors, etc. I wrote
> some code using SqrtPixelAdaptor (AddPixelAccessor will not compile, see
> below) to test the Set() and Get() methods.
> For an image set to 100:
> - Get() returns 10 as expected.
> - Set(10) sets the pixel to sqrt(10), and followed by Get() returns the
> sqrt(sqrt(10)), which is what you warned me about. But is this the intended
> use of Set()?
> Back to your example with AddPixelAccessor:
> It is my understanding that image adaptors behave like images. So SetPixel
> would set the pixel value according to the pixel accessor used. So, by your
> example, SetPixel(12) would ultimately just set the pixel to "7", which is
> the value of the input image. It allows Get() to be used correctly, but
> doesn't seem too useful.

Why not ?

What other use should we expect
from the Get() / Set() methods ?

> Considering that itkAddPixelAccessor will not compile and there is no test
> for it,


The lack of test is a bug.

I'm fixing that one using the one by starting
from the file that you kindly provided.


> and that its Set() method does not follow the other Accessors, is it
> possible that the functionality for Set() was changed some time ago
> and itkAddPixelAccessor  fell through the cracks?


That's a plausible theory,...

but experimental inspection reveals that
this is not the case:

The following command will show you the
history of these two classes.

  gitk itkAddImageAdaptor.h
  gitk itkAddPixelAccessor.h
  gitk itkCosImageAdaptor.h

  git log -- itkAddPixelAccessor.h
  git log -- itkAddImageAdaptor.h
  git log -- itkCosImageAdaptor.h

---

   "Glimpsing at the source,
    leaves no doubt"


      Luis


-----------------------------
> Thanks.
> ********
> I attempted to write test code for AddPixelAccessor, but am getting compile
> errors:
> typedef itk::AddPixelAccessor<float> AddAccessorType;
> itkAddPixelAccesor.h: No such file or directory
> I made a copy of itkAddPixelAccesor.h (itkTestAddPixelAccessor.h), and
> received the following error:
> error: expected initializer before'<' token
> which usually means the header wasn't included...
> I moved #include "itkTestAddPixelAccessor.h" to the top of my include list
> and got the following error:
> itkTestAddPixelAccessor.h:39: error: invalid function declaration
> Consider me perplexed...