-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Geometric information parameterization #584
Comments
Heya! Questions: 1- Why are you doing this? |
Thank you very much for your reply: 1. The current software package uses a flat detector, and I want to extend it to any geometric arrangement of the detector. By directly entering the coordinates of the detector in the.m file, the arrangement of the detector can be directly defined. 2, the first image is correct, the second image is the current calculation of the image, the projection Angle of the second and the first is equal in size, the difference is that the projection Angle of the first as a single Angle to calculate the input, the second is a projection Angle array containing this Angle.
…---- Replied Message ----
| From | ***@***.***> |
| Date | 09/18/2024 19:00 |
| To | ***@***.***> |
| Cc | ***@***.***>***@***.***> |
| Subject | Re: [CERN/TIGRE] Geometric information parameterization (Issue #584) |
Heya!
Questions:
1- Why are you doing this?
2- The images you shown, are they expected vs current result?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Hi @daxiaojiupang You need to explain that with a little bit more detail, your second point is not very understandable. Can you please explain better what the differences are? |
For example, the input projection angle of the first drawing is angle= [0.2], and the second drawing is the orthographic image corresponding to 0.2 radians drawn by the input projection Angle is Angle = [0,0.2, 0.3].
…---- Replied Message ----
| From | ***@***.***> |
| Date | 09/18/2024 19:18 |
| To | ***@***.***> |
| Cc | ***@***.***>***@***.***> |
| Subject | Re: [CERN/TIGRE] Geometric information parameterization (Issue #584) |
Hi @daxiaojiupang You need to explain that with a little bit more detail, your second point is not very understandable. Can you please explain better what the differences are?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
So both of the examples here are from your code, not the basic TIGRE code? |
Yes, both are based on the TIGRE code. Not basic code.
…---- Replied Message ----
| From | ***@***.***> |
| Date | 09/18/2024 19:26 |
| To | ***@***.***> |
| Cc | ***@***.***>***@***.***> |
| Subject | Re: [CERN/TIGRE] Geometric information parameterization (Issue #584) |
So both of the examples here are from your code, not the basic TIGRE code?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
In any case, these things are not very trivial to debug. I suggest changing the outputs of your codes to e.g. output the index of the detector rather than the integral, so you can see if the line is being computed, at least. That way you know if there is an issue in function calls or in numerical values. This could be many things. A possibility could be e.g. that you are copying the memory out before syncronizing the stream, for example, but you didn't post the entire code, so I can't know for sure. It could also be npixelXYZ overflow. Not sure what this is supposed to be, but if its the number of pixels in the detector (you already have access to this value in the geometry!) then an It could also be bad use of symbols. You seem to be copying all detector locations into a symbol? They are not created for this big amount of data, even if it may work. I would instead put them in a constant memory array on the device, and then read this array. Or something else, who knows, these things are quite hard to debug. Try any of the above and let me know. However, if you are looking to add support to curved detectors (where pixel distances to the source are equal) there are easier ways than this. Crucially, its better to either "flatten" the projections, or instead just make the projector code assume equal distances and compute the location of the pixels accordingly, with no need to input any memory to the GPU. |
Thank you for your suggestion. I will continue to adjust the code, and I will share with you in time if there is any new progress.
…---- Replied Message ----
| From | ***@***.***> |
| Date | 09/18/2024 19:41 |
| To | ***@***.***> |
| Cc | ***@***.***>***@***.***> |
| Subject | Re: [CERN/TIGRE] Geometric information parameterization (Issue #584) |
In any case, these things are not very trivial to debug. I suggest changing the outputs of your codes to e.g. output the index of the detector rather than the integral, so you can see if the line is being computed, at least. That way you know if there is an issue in function calls or in numerical values.
This could be many things. A possibility could be e.g. that you are copying the memory out before syncronizing the stream, for example, but you didn't post the entire code, so I can't know for sure.
It could also be npixelXYZ overflow. Not sure what this is supposed to be, but if its the number of pixels in the detector (you already have access to this value in the geometry!) then an int won't cut it, likely. You want a size_t or a unsigned long long.
It could also be bad use of symbols. You seem to be copying all detector locations into a symbol? They are not created for this big amount of data, even if it may work. I would instead put them in a constant memory array on the device, and then read this array.
Or something else, who knows, these things are quite hard to debug. Try any of the above and let me know.
However, if you are looking to add support to curved detectors (where pixel distances to the source are equal) there are easier ways than this. Crucially, its better to either "flatten" the projections, or instead just make the projector code assume equal distances and compute the location of the pixels accordingly, with no need to input any memory to the GPU.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
@AnderBiguri
Thanks for your help, through repeated adjustments finally solved the problem caused by the array passed from the cpu to the GPU memory allocation error.
However, I have encountered the following problems, and hope to get your help. In the backprojection calculation, I store the left and right y values of each pixel in the first row in two arrays, and the upper and lower Z values of each pixel in the first column in two arrays, which is used to compute u and v. The following changes are made to voxel_backprojection. Figure 1 is the result of the original code. Figure 2 shows the result of the modified code. May I ask what other aspects I have not considered to make modifications? I am looking forward to your reply.
////Original code//////////////////
// Get the coordinates in the detector UV where the mid point of the voxel is projected.
float t=__fdividef(DSO-DSD-S.x,vectX);
float y,z;
y=vectY*t+S.y;
z=vectZ*t+S.z;
float u,v;
u=y+(float)geo.nDetecU*0.5f;
v=z+(float)geo.nDetecV*0.5f;
voxelColumn[colIdx]+=tex3D<float>(tex, v, u ,indAlpha+0.5f)*weight;
////Modified code/////////////////
// Get the coordinates in the detector UV where the mid point of the voxel is projected.
float t=__fdividef(DSO-DSD-S.x,vectX);
float y,z;
y=vectY*t+S.y;
z=vectZ*t+S.z;
int u = -1;
float uFrac = 0.0f; // Store the floating point u after interpolation
//i represents the index of the I-th pixel of the first row of pixels.
//The U_left[i] array stores the y coordinate to the left of the pixel,
//and the U_left[i] array stores the y coordinate to the right of the pixel.
for (int i = 0; i < geo.nDetecU; i++) {
if (y >= U_left[i] && y <= U_right[i]) {
u = i;
// The relative position of y in this interval is calculated and interpolated
float range = U_right[i] - U_left[i]; // Interval length
if (range > 0.0f) {
uFrac = (y - U_left[i]) / range; // Relative position, between 0.0 and 1.0
}
break;
}
}
if (u == -1) {
// Coordinates are out of range. Skip it
continue;
}
int v = -1;
float vFrac = 0.0f; // Stores the floating point v after interpolation
//i represents the index of the I-th pixel of the first column pixel, the z coordinate of the upper side of the pixel in the V_top[i] array store,
//and the z coordinate of the lower side of the pixel in the U_bot[i] array store.
for (int i = 0; i < geo.nDetecV; i++) {
if (z >= V_bot[i] && z <= V_top[i]) {
v = i;
//The relative position of z in the interval is calculated and interpolated
float range = V_bot[i] - V_top[i]; // Interval length
if (range > 0.0f) {
vFrac = (z - V_bot[i]) / range; // Relative position, between 0.0 and 1.0
}
break;
}
}
if (v == -1) {
// Z-coordinates are out of range. Skip it
continue;
}
// Compute floating point u and v for texture sampling
float u_float = (float)u + uFrac;
float v_float = (float)v + vFrac;
//Texture sampling using interpolated u_float and v_float
voxelColumn[colIdx] += tex3D<float>(tex, u_float, v_float, indAlpha + 0.5f) * weight;
<img width="362" alt="Fig1" src="https://github.com/user-attachments/assets/db0c0137-982c-463d-8ed4-0ff98e8b1695">
<img width="348" alt="Fig2" src="https://github.com/user-attachments/assets/e8670857-3083-4324-9162-9e1adc72233f">
|
hi @daxiaojiupang , I can't see any figures. Can you also edit the post so its a bit more readable (code blocks etc) please? |
Hi,
I see. Apologies for insisting, but it would be easier if you put these in
the github issue rather than replying to the email, as they seem to be not
being posted there. I will lose track of information if it's not in the
same place.
Thanks
…On Sat, 28 Sept 2024, 11:52 daxiaojiupang, ***@***.***> wrote:
@AnderBiguri
Thanks for your help, through repeated adjustments finally solved the
problem caused by the array passed from the cpu to the GPU memory
allocation error.
However, I have encountered the following problems, and hope to get your
help. In the backprojection calculation, I store the left and right y
values of each pixel in the first row in two arrays, and the upper and
lower Z values of each pixel in the first column in two arrays, which is
used to compute u and v. The following changes are made to
voxel_backprojection. Figure 1 is the result of the original code. Figure 2
shows the result of the modified code. May I ask what other aspects I have
not considered to make modifications? I am looking forward to your reply.
////Original code//////////////////
// Get the coordinates in the detector UV where the mid point of the voxel
is projected.
float t=__fdividef(DSO-DSD-S.x,vectX);
float y,z;
y=vectY*t+S.y;
z=vectZ*t+S.z;
float u,v;
u=y+(float)geo.nDetecU*0.5f;
v=z+(float)geo.nDetecV*0.5f;
voxelColumn[colIdx]+=tex3D<float>(tex, v, u ,indAlpha+0.5f)*weight;
////Modified code/////////////////
// Get the coordinates in the detector UV where the mid point of the voxel
is projected.
float t=__fdividef(DSO-DSD-S.x,vectX);
float y,z;
y=vectY*t+S.y;
z=vectZ*t+S.z;
int u = -1;
float uFrac = 0.0f; // Store the floating point u after interpolation
//i represents the index of the I-th pixel of the first row of pixels.
//The U_left[i] array stores the y coordinate to the left of the pixel,
//and the U_left[i] array stores the y coordinate to the right of the
pixel.
for (int i = 0; i < geo.nDetecU; i++) {
if (y >= U_left[i] && y <= U_right[i]) {
u = i;
// The relative position of y in this interval is calculated and
interpolated
float range = U_right[i] - U_left[i]; // Interval length
if (range > 0.0f) {
uFrac = (y - U_left[i]) / range; // Relative position, between 0.0 and 1.0
}
break;
}
}
if (u == -1) {
// Coordinates are out of range. Skip it
continue;
}
int v = -1;
float vFrac = 0.0f; // Stores the floating point v after interpolation
//i represents the index of the I-th pixel of the first column pixel, the
z coordinate of the upper side of the pixel in the V_top[i] array store,
//and the z coordinate of the lower side of the pixel in the U_bot[i]
array store.
for (int i = 0; i < geo.nDetecV; i++) {
if (z >= V_bot[i] && z <= V_top[i]) {
v = i;
//The relative position of z in the interval is calculated and
interpolated
float range = V_bot[i] - V_top[i]; // Interval length
if (range > 0.0f) {
vFrac = (z - V_bot[i]) / range; // Relative position, between 0.0 and 1.0
}
break;
}
}
if (v == -1) {
// Z-coordinates are out of range. Skip it
continue;
}
// Compute floating point u and v for texture sampling
float u_float = (float)u + uFrac;
float v_float = (float)v + vFrac;
//Texture sampling using interpolated u_float and v_float
voxelColumn[colIdx] += tex3D<float>(tex, u_float, v_float, indAlpha +
0.5f) * weight;
<img width="362" alt="Fig1" src="
https://github.com/user-attachments/assets/db0c0137-982c-463d-8ed4-0ff98e8b1695">
<img width="348" alt="Fig2" src="
https://github.com/user-attachments/assets/e8670857-3083-4324-9162-9e1adc72233f">
—
Reply to this email directly, view it on GitHub
<#584 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2OENF6OJU7XMAS3YRB3PTZY2C7RAVCNFSM6AAAAABOMWMCIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYGU2TIOJRG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
However, in any case, I'm not sure I can debug a highly complex code just
with a little piece of it and a figure...
Ander
…On Sat, 28 Sept 2024, 12:46 Ander Biguri, ***@***.***> wrote:
Hi,
I see. Apologies for insisting, but it would be easier if you put these in
the github issue rather than replying to the email, as they seem to be not
being posted there. I will lose track of information if it's not in the
same place.
Thanks
On Sat, 28 Sept 2024, 11:52 daxiaojiupang, ***@***.***>
wrote:
> @AnderBiguri
> Thanks for your help, through repeated adjustments finally solved the
> problem caused by the array passed from the cpu to the GPU memory
> allocation error.
> However, I have encountered the following problems, and hope to get your
> help. In the backprojection calculation, I store the left and right y
> values of each pixel in the first row in two arrays, and the upper and
> lower Z values of each pixel in the first column in two arrays, which is
> used to compute u and v. The following changes are made to
> voxel_backprojection. Figure 1 is the result of the original code. Figure 2
> shows the result of the modified code. May I ask what other aspects I have
> not considered to make modifications? I am looking forward to your reply.
>
>
> ////Original code//////////////////
> // Get the coordinates in the detector UV where the mid point of the
> voxel is projected.
> float t=__fdividef(DSO-DSD-S.x,vectX);
> float y,z;
> y=vectY*t+S.y;
> z=vectZ*t+S.z;
> float u,v;
> u=y+(float)geo.nDetecU*0.5f;
> v=z+(float)geo.nDetecV*0.5f;
>
> voxelColumn[colIdx]+=tex3D<float>(tex, v, u ,indAlpha+0.5f)*weight;
>
> ////Modified code/////////////////
> // Get the coordinates in the detector UV where the mid point of the
> voxel is projected.
> float t=__fdividef(DSO-DSD-S.x,vectX);
> float y,z;
> y=vectY*t+S.y;
> z=vectZ*t+S.z;
> int u = -1;
> float uFrac = 0.0f; // Store the floating point u after interpolation
> //i represents the index of the I-th pixel of the first row of pixels.
> //The U_left[i] array stores the y coordinate to the left of the pixel,
> //and the U_left[i] array stores the y coordinate to the right of the
> pixel.
> for (int i = 0; i < geo.nDetecU; i++) {
> if (y >= U_left[i] && y <= U_right[i]) {
> u = i;
> // The relative position of y in this interval is calculated and
> interpolated
> float range = U_right[i] - U_left[i]; // Interval length
> if (range > 0.0f) {
> uFrac = (y - U_left[i]) / range; // Relative position, between 0.0 and
> 1.0
> }
> break;
> }
> }
> if (u == -1) {
> // Coordinates are out of range. Skip it
> continue;
> }
> int v = -1;
> float vFrac = 0.0f; // Stores the floating point v after interpolation
> //i represents the index of the I-th pixel of the first column pixel, the
> z coordinate of the upper side of the pixel in the V_top[i] array store,
> //and the z coordinate of the lower side of the pixel in the U_bot[i]
> array store.
> for (int i = 0; i < geo.nDetecV; i++) {
> if (z >= V_bot[i] && z <= V_top[i]) {
> v = i;
> //The relative position of z in the interval is calculated and
> interpolated
> float range = V_bot[i] - V_top[i]; // Interval length
> if (range > 0.0f) {
> vFrac = (z - V_bot[i]) / range; // Relative position, between 0.0 and 1.0
> }
> break;
> }
> }
> if (v == -1) {
> // Z-coordinates are out of range. Skip it
> continue;
> }
> // Compute floating point u and v for texture sampling
> float u_float = (float)u + uFrac;
> float v_float = (float)v + vFrac;
>
> //Texture sampling using interpolated u_float and v_float
> voxelColumn[colIdx] += tex3D<float>(tex, u_float, v_float, indAlpha +
> 0.5f) * weight;
>
> <img width="362" alt="Fig1" src="
> https://github.com/user-attachments/assets/db0c0137-982c-463d-8ed4-0ff98e8b1695">
>
>
> <img width="348" alt="Fig2" src="
> https://github.com/user-attachments/assets/e8670857-3083-4324-9162-9e1adc72233f">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> —
> Reply to this email directly, view it on GitHub
> <#584 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AC2OENF6OJU7XMAS3YRB3PTZY2C7RAVCNFSM6AAAAABOMWMCIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYGU2TIOJRG4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
@AnderBiguri
|
In principle what you are saying is fine of course... but the devil is in the details I guess... |
Thanks for your reply. After my unremitting efforts, I finally found the reason. Now the program has been debugged.
…---- Replied Message ----
| From | ***@***.***> |
| Date | 09/30/2024 20:12 |
| To | ***@***.***> |
| Cc | ***@***.***>***@***.***> |
| Subject | Re: [CERN/TIGRE] Geometric information parameterization (Issue #584) |
In principle what you are saying is fine of course... but the devil is in the details I guess...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Expected Behavior
Actual Behavior
My purpose is to enter the detector coordinates directly in the.m file, DetectorXYZ is a one-dimensional array that stores the detector coordinates, the modified code is as follows. The orthographic image calculated when a single Angle is entered is the first, and the orthographic image calculated when the input projection Angle is an array is the second. The projection Angle of the first image and the second image is the same, the calculated orthographic image is inconsistent, is there anything in the code that has not been modified? Please help me check.
Code to reproduce the problem (If applicable)
matlab code:
Specifications
The text was updated successfully, but these errors were encountered: