https://github.com/MITK/MITK/pull/71

It implements the is_const and remove_const types if the compiler does not support C++ 11. This case works well. I have not tested it with a compiler *with* C++ 11, though.

I have not noticed 15821, but I have started working on the same issue already.

I think this bug does not block 15821, in contrary, 15821 depends on this.

I will add my findings to that ticket.

The pull request looks in principal good to me, but I didn't fully understand the changes in the mitkImageAccessByItk.h file. Did you add the "accessByType" macros because you wanted to use a mitk::Image inside the templated access methods or would the old approach still fit your needs (if it does the "correct" thing for const/non-const mitk::Image inputs)?

There are three things that you can do with the AccessByType macros but not with AccessByItk:

1. Put read lock instead of write lock on the input MITK image.
2. Set the locking policy, e.g. IgnoreLock
3. Sometimes you do not really want to convert the image, you just want to know the pixel type and dimension at compile time.

For 1:
This would not be needed if the AccessByItk would choose the right locking type (read/write) e.g. based on the constness of the first argument. See #15821.

2. and 3. is rarely needed, but the current API does not cover those cases.

I currently need only 1, but not 2 and 3.

Moreover, the AccessByType is not an ideal solution for 1 at all, because you need to write lots of wrapper functions that create an ImageToItk inside.

So, I wrote it, but at the end I do not use it because it would be too much work to replace the AccessByItk calls by functions throughout our code base. Instead of this, I invested some time on a metaprogramming solution for #15821. That would be much more important.

That is, if you do not like it, you can just pull the previous commit.

Thanks for the update. I am just trying to minimze new code and maintenance overhead.

Issue 2. could maybe also be covered by AccessByItk and if 3. isn't used or very seldomly used, I would just "ignore" it for now (there is a work-around including the itk::Image conversion anyway).

Fair enough.

User zelzer has pushed new remote branch:

bug-17931-ImageToITK-read-lock

I just added my version of fixing this bug and 15821, based on Miklos GitHub pull request.

What I added on top of Miklos branch (without the last commit, which adds new AccessByType macros) is:

1. Make the ImageReadAccessor constructor take const mitk::Image objects
2. Use function overloads in the AccessyByItk macro based on the constness of the mitk::Image argument to select the correct read/write accessor and the correct templated access function (no template magic used).

Could you please review? I only tested this on Linux yet.

Tested now also on Windows and everything seems to work fine.

All good.
MITKCore compiles and tests pass on Mountain Lion with gcc 4.2.1 (default compiler).

[951c87]: Merge branch 'bug-17931-ImageToITK-read-lock'

Merged commits:

2014-08-15 11:47:59 Sascha Zelzer [ce8ace]
Fixed inconsistent header guards.

2014-08-15 11:47:43 Sascha Zelzer [a5a2aa]
Fixed private member access error on Clang.