We can observe that when the dimension of A is a multiple of 2, pixel information is misplaced (top-left-corner) or lost (bottom-right-corner)
1st-row L-to-R: Shows an original image GREEN, then its MATLAB's radon transform (a.k.a. sinogram), then its MATLAB's inverse radon transform REED (aka iradon), then the position comparison between the original and reconstructed, NON-MATCHING pixel position: SEPARATE COLORS.
2nd-row L-to-R: Shows my manually modified sinogram, then its MATLAB's iradon REED, then the position comparison between the original and reconstructed, MATCHING pixel position: GREEN+RED=YELLOW.
On line 50 I partially "fixed" the RT of the image so iRT would interpret the posiitons of the backprojections (potbp) in the proper place. I say partially because I changed all projection values to a new (better) relative distance for iradon to interpret, which here is enough to show the radon-iradon reconstruction issue.
The cross-like pattern surrounding the main FIXED reconstructed pixel (red pixels on 2 row of the figure) because the precise fixed potbp should follow a sinosoidal shifting pattern (with more spare time you can do it, but I suggest to better fix the reconstruction rule on iradon), thus it would give no cross-like pattern.
Can you please tell me how can you distinguish an original pixel next to a reconstructed pixel when both are grey? in other words do you think gray levels are more helpful to compare POSITIONS of original (could be green) with iradon reconstructed pixels (could be red)?
If you run the code read comments you would notice that all the radon and iradon transformations are done in 2-D (not RGB) but I tried to just display them in different colors for making obvious different parts of the process.
...to use grey colorbars, what for?
So by "better phantom" I hope you don't mean one that hides that a pixel was lost in the iradon right-bottom edge. At least I didn't want that, this is meant to be a pixel-to-pixel bijection test.
...use larger phantom image? Instead of getting the whole idea from the cover image, I invite you to read and run whatever else the code does, when you do that you'll see that the test is in a "for"cycle that makes larger and larger phantom images and you can further modify it to test it with even larger phantoms.
Everyone can observe the lost pixes by iradon and the informal-quick-fix manual recovery of them by modifying the sinogram, try it!
Rounding behaviors are documented by Matlab as that, this one never had, and if for you, a all pair-sized images ranging from 2 to 2x10^n are "limited sizes" I understand this is not a "matlab bug" for you
2nd paragraph -> "run the code and read the comments"
bottom line, although the error is subtle enough not to be noticed, is visible with the scaling test I made and the sinogram controlling mechanism I described. I think this is crucial for any serious image processing developer that relies on this transform accuracy, I found this issue when I was testing it to construct another application based on it and was not working properly , thats why I made my own radon and iradon, but I concerned that matlab has not changed or detected that in years and programmers are still using them.
use gray levels rather than RGB and add the (gray) colorbars ...
use a better phantom ! (eg. one cross or a L or a more complex gray phantom rather than a BW)
use a larger phantom image.
in my view it is not a matlab bug ... just rounding behaviour relater to the limited size of your image...
Download apps, toolboxes, and other File Exchange content using Add-On Explorer in MATLAB.