New feature - using bounding box facets to detect photons

[Fang, Qianqian]

hi everyone,

I wrote a detailed reply regarding how photons are detected in mcx/mmc, thought that it might be helpful if I share it in the mailing list as well.

in this reply, I want to highlight approach #2 - a newly implemented feature - to allow capturing photons at the bounding box facets by setting the 7-12th letters in cfg.bc. for example, cfg.bc='______1001' captures all photons escaping from x=0 and x=max_x. This makes it possible to define rectangular detectors instead of a disk-shaped ones. To use this feature, please download the nightly build versions of mcx/mcxcl.

see my full reply below, feel free to chime in if you have any additional questions.

Qianqian

https://github.com/fangq/mcx/issues/102#issuecomment-682093350

fangq commented 14 minutes ago • 

edited 

@CGLemon, let me first explain how mcx detectors captures photons. there are currently 3 ways to capture photons in mcx/mcxcl using a detector (cfg.detpos = [dx, dy, dz, Rd], use cfg.savedetflag to decide what data to store). A photon is captured by a detector only if both of the below conditions are met: 1) they are trying to escape from the domain (any non-zero voxel) to the background (zero-valued voxel or outside of the bounding box), and 2) the exit position is within a sphere (radius Rd) centered at the nearest detector. you can see that these two conditions restrict that a captured photon must be located on the bounding box/an interface between zero and non-zero voxels, truncated by a sphere centered at a given detector. if the above conditions are met, a photon will be captured, regardless of their propagation direction. you can, however, set cfg.issaveexit=1 or append letters 'xv' in cfg.savedetflag to store the exit position detpt.p and exit direction vector detpt.v. If your actual physical detector has an NA that limits the incident photon angles, you can then use detp.{p,v} to figure out if it will be detected by your camera/optics in a post processing. to show what this means, here is the plot of the detected photon positions when a series of detectors is placed on a curved volume, you can see that they are limited to the voxel boundaries. in the latest github version of mcx/mcxcl, I added a new way to detect photons on the bounding box. One can set digits 7-12 in the cfg.bc='______000000' input to ask mcx to capture all photons escaping from the 6 bounding box facets: x=0,y=0,z=0,x=Nx, y=Ny, z=Nz planes, respectively according to the orders of the letters - a letter '1' indicates that you want to capture all photons escaping from that plane, a letter '0' - do not capture. This way, you can define a rectangle-shaped detector but only on the bounding box.the output data are similar to a spherical detector, where you can use cfg.savedetflag to get various info, including exit position and angle. More details, please see https://github.com/fangq/mcx/blob/master/README.txt#L244-L250 you can also run this sample script to get a demo: https://github.com/fangq/mcx/blob/master/mcxlab/examples/demo_bc_det.m you can use cfg.issaveref to accumulate total diffuse reflectance within zero-valued voxels immediately adjacent to a non-zero valued voxel. This gives you the distribution of light leaking from the entire surface of the object, as long as you pad a layer of zeros around the object. This accumulated surface light distribution does not store individually detected photon information, instead, their final weight are summed together regardless of their escaping directions. This is more memory efficient, but does not provide the granularity if you want to individually process the detected photon. Lastly, I want to highlight that both mcx and mmc have the capability of modeling wide-field detectors (i.e. non contact), as long as you discretize the space between the detector and the domain and include that as part of your volume (in mcx) or mesh (in mmc). An example of this can be seen for mmc in Fig. 7 of our wide-field mmc paper - a rectangular detector can be placed outside of the object as long as you tessellate the gap between them. Please be aware that any empty space between your widefield source/detector in mcx/mcxcl, if they are rasterized, must be labeled as a non-zero label with an optical property of air, instead of setting it to zero-valued voxel. This is because zero-valued voxels are special in mcx/mcxcl as the background, as I mentioned above, a photon moving from a non-zero voxel to a zero-voxel will be terminated, so they won't make it to the wide-field detector. let me know if these addresses your questions.

[Giulia Maffeis]

Hello Qianqian,

I hope this message finds you well. I am writing in this group to ask further confirmation about the detector’s operation. You say that a photon is collected by the detector provided that:

1.  it exits the medium’s volume;

2.  the exit position is within a sphere centered at the nearest detector.

Then, the “effective” detector is the surface deriving from the intersection between the medium’s boundary and the sphere, correct? The image titled “VMC” you uploaded suggests this interpretation.

Nevertheless, I am not sure about it because the domain preview generated by the “mcxpreview” command in MCX always depicts the detector as a sphere.

Thank you in advance for your answer.

Giulia

[Fang, Qianqian]

On 2/3/21 5:42 AM, Giulia Maffeis wrote:

Hello Qianqian,

I hope this message finds you well. I am writing in this group to ask further confirmation about the detector’s operation. You say that a photon is collected by the detector provided that:

1.  it exits the medium’s volume;

2.  the exit position is within a sphere centered at the nearest detector.

Then, the “effective” detector is the surface deriving from the intersection between the medium’s boundary and the sphere, correct? The image titled “VMC” you uploaded suggests this interpretation.

yes, this is correct if you define cfg.detpos to capture detected photos.

the cfg.bc flag (bytes 7-12) I mentioned below is an alternative way to define detectors, a detection plane defined by cfg.bc only works at the bounding box facets.

Nevertheless, I am not sure about it because the domain preview generated by the “mcxpreview” command in MCX always depicts the detector as a sphere.

currently mcxpreview does not support rendering bounding box based detection planes. but this is just visualization, the cfg.bc setting should still work regardless.

let me know if this is clear.

Qianqian

--
You received this message because you are subscribed to the Google Groups "mcx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mcx-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mcx-users/687dd80a-e677-4e11-9301-1c66aa5c3d56n%40googlegroups.com.

[G Buist]

Dear Qianqian,

If possible I would like some clarification on the workings of the --bc option.

             1. Is it correct that the plane detectors of --bc are not counted in the 'DetNum' value?

             2. Does every plane have the same detector id ('detid')?

                    I used -bc ______001001 and got only detid's of 4294967295 in my detid list while I expect both planes to detect

             3. What happens when there is an overlap between a detector defined in 'Optode'  and a plane detector from --bc?

Thanks in advance for your answer.

Gijs

Op woensdag 3 februari 2021 om 19:19:42 UTC+1 schreef Fang, Qianqian:

[Qianqian Fang]

On 10/25/21 3:25 AM, 'G Buist' via mcx-users wrote:

Dear Qianqian,

If possible I would like some clarification on the workings of the --bc option.

             1. Is it correct that the plane detectors of --bc are not counted in the 'DetNum' value?

this is correct

             2. Does every plane have the same detector id ('detid')?

                    I used -bc ______001001 and got only detid's of 4294967295 in my detid list while I expect both planes to detect

the detid for --bc based detector is -1 if you typecast uint32(4294967295) to a signed integer (int32), it comes from this line

https://github.com/fangq/mcx/blob/v2020.9/src/mcx_core.cu#L186

             3. What happens when there is an overlap between a detector defined in 'Optode'  and a plane detector from --bc?

the --bc/detid=-1 flag will have a higher priority over the detectors defined in the Optode, again, based on the line above.

Qianqian

To view this discussion on the web visit https://groups.google.com/d/msgid/mcx-users/554399de-bb86-449d-abfb-674490550f44n%40googlegroups.com.