Small bug #11
Description
Hi Hendriks And Lars!
I believe that In the class "L1AnisoProxDualShift" there is a "bug" in the constructor, as there is no word "Shift" in it. You may not have noticed it because the class might be unused (I did not find it from the UML -sheets). The reason for that might have something to do with the nature of anisotropic total variation. At least at the moment it is a redundant class with exactly the same code as the normal "L1AnisoProxDual". So you have probably copy-pasted and forgot to add "Shift" to the constructor.
I do not know what the word "shift" refers to, but I am using flexbox (Congrats for building it!) in my research, and added a new operator there which (first optionally upsamples) and then shifts the image reconstruction space in ROF-model f.e. half a pixel up and right. (Naturally I used the word "shift" there and did exactly the same copy pasteing error at first.) Now I am trying to understand the actual algorithm in order to be sure that I am using the right prox for it. I believe that the normal "L1AnisoProxDual" is enough as the bit non-standard gradient-operator already takes into account that the jumps between two image boundary pixels has a suitable weight in the anisotropic total variation.
If you like the idea of shifting the reconstruction space (The idea is from professor Samuli Siltanen, who is the leader of the research group in the University of Helsinki), I would be glad to share my simple add-on to the code. (Of course there is already an option for customized linear operators so I understand that you are not necessarily interested on this one.) At least it produces quite nice upsampling with anisotropic TV, which can not be used in normal upsampling. The upsampling is also invariant for 90 degrees rotation unlike isotropic TV upsampling.