0-360 data collection

[decarlof]

@canismarko @aps-7bm @nikitinvv:

there are currently two options to reconstruct 0-360 data sets collected with the rotation axis on one side

--file-type flip_and_stich --rotation-axis-flip 10

and

--file-type double_fov --rotation-axis 10

these look very similar. The only difference I can really see is that the first does the flip@stitch at file reading accounting for the overlapping area and generates flip&stitch data with different H size depending from the location of the rotation axis. The second does the flip&stitch with normalized data (just before the reconstruction) and uses a fixed double H size.

The first adds its own find_center, the second does not support find_center yet.

The first adds to --rotation-axis (that is still the location of the rotation axis but now in in the larger array) the --rotation-axis-flip parameter to indicate the location of the rotation axis in the raw data where to make the flip.

Any suggestion on how to consolidate the two so they are compatible with any other option applied after file reading (like the existing find_center used in the 0-180 scan for example)?

[aps-7bm]

I use this pretty extensively, actually. I would be interested to see what Viktor has come up with. If it works better, I'm all ears.

On Wed, Jul 21, 2021 at 6:06 PM Francesco De Carlo @.***> wrote:

@canismarko https://github.com/canismarko @aps-7bm https://github.com/aps-7bm do you use the

--file-type flip_and_stich --rotation-axis-flip 10

option to reconstruct 0-360 data sets collected with the rotation axis on one side ?

If not I will remove it. @nikitinvv https://github.com/nikitinvv developed a new method accessible with

--file-type doube_fov --rotation-axis 10

that does the same in a better way

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tomography/tomopy-cli/issues/73, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOHRUKNGB27J7BPH4E4AULTY5HILANCNFSM5AY4RGMA .

[canismarko]

I don't really use find_center much for the 360° tomograms, but I do use --reconstruction-type try, is that supported in --file-type double_fov?

I like having --rotation-axis be the one and only way of specifying the rotation axis.

Has anyone checked that the two methods actually produce identical results?

[aps-7bm]

I tried out the new double_fov option this morning. I noticed a few differences between how flip_and_stich and double_fov behave. I had some normal 0-180 degree scans of similar samples (same composition but smaller extent) for comparison. Using flip_and_stich gives me similar grayscale values to the 0-180 degree scans. Using double_fov gives significantly lower values, I'm assuming because the dataset is padded with zeros. The results from double_fov are also rotated 180 degrees about the rotation axis compared to flip_and_stich. Finally, the reconstructed datasets are much larger (2 * the projection image width) than with flip_and_stich (size depends on the rotation center). FWIW, the rotation centers found with double_fov work for flip_and_stich as well. As such, I would like to keep flip_and_stich for now. What might be useful is to only have one rotation center variable; it gets too confusing to have two.

[aps-7bm]

[aps-7bm]

In these images, the top image is from a 0-180 degree scan. The middle image is with double_fov. The bottom image is from the same slice as the second image but using flip_and_stich. For these images, beam hardening corrections have been applied in the same way. The grayscale range is the same (this is why the brightness varies). The same rotation center was used for both 0-360 cases.

[decarlof]

@aps-7bm thank you for doing this. It was on my to do list ... you are correct the zero padding has an effect on the values and this will not be acceptable if users collecting 0-180 and 0-360 on same material want to do any quantitative comparison of density values. Also agree we should have a single meaning / definition for --rotation-axis . That I think was the reason we introduced in the 0-360 scan the --rotation-axis-flip (location or the rotation axis around which to do the flip) and kept --rotation-axis as the location of the rotation axis (that in a 0-360 has a zero on the left of the stitched image). Also I like that the --rotation-axis-flip acts at file read time => other downstream methods are going to work.

Let's keep --rotation-axis-flip as is and rework the --file-type double_fov

[nikitinvv]

I think double_fov is very crucial for txm images. With double_fov one doesnt need to find overlapping region, as opposed to the flip_and_stitch with the option --rotation-axis-flip. So it basically works as a regular reconstruction where only --rotation-axis is specified. For txm measurements this overlapping region is sometimes very difficult to find. In many cases, after stitching there is a discontinuity in the stitching region, caused by irregularity of flat fields. This may also create artifacts. This shouldnt be significant for the double_fov mode because there is no stitching inside it, everything is done in the Fourier domain.

We can add projections cropping and adjusting the constant multiplier to have similar results with the flip_and_stitch method. There is no requirement for overlap in the double_fov method, you can have overlap=0 or 1 pixel and it will work fine. Thats why I decided not to add cropping at the beginning. But I will add it soon.

The main disadvantage of the double_fov is performance. It should be 2x slower because 2x more angles are used for reconstruction (of course after adding projections cropping).

I agree, lets keep both methods.

[decarlof]

Ok let's keep them both then, I did not think about the TXM case. What tricked me is that I have seen the --file-type double_fov used at 2-BM for micro CT data as the regular 0-360 reconstruction method.

We still need to clarify the meaning of --rotation-axiswhen using the --file-type double_fovoption (perhaps in the command docs) and limit the options of not supported commands (like find_center that now has access to all recon parameters).

[nikitinvv]

I would say that meaning of rotation axis in double_fov is natural. We have centers either on one side (e.g. 10-50), or on another side (e.g. 2300-2400), which directly corresponds to what we see on the detector.