http://www.k-wave.org/forum/topic/x-upward-shift-in-image Support for the k-Wave MATLAB toolbox en-US Wed, 13 May 2026 00:53:55 +0000 http://bbpress.org/?v=1.0.2 q http://www.k-wave.org/forum/search.php http://www.k-wave.org/forum/topic/x-upward-shift-in-image#post-6596 Mon, 08 Oct 2018 13:48:21 +0000 Alexll7 6596@http://www.k-wave.org/forum/ <p>Hi Bradley,</p> <p>Yes, I changed everytime "steering_angle_max" when I increased the range of "steering_angles" (I've just verified it this minute with the saves of the parameters of my simulations).<br /> Thank you very much for your confirmation.<br /> Kind regards,</p> <p>Alex </p> http://www.k-wave.org/forum/topic/x-upward-shift-in-image#post-6594 Sun, 07 Oct 2018 20:29:46 +0000 Bradley Treeby 6594@http://www.k-wave.org/forum/ <p>Hi Alexandre,</p> <p>Your example and description look pretty convincing - I think it's a genuine bug. Thanks for taking the time to get to the bottom of it and posting your fix! I'll add it to the list for the next release. Can I double check that you also changed the value of <code>transducer.steering_angle_max</code> when you increased the range of steering angles?</p> <p>Brad. </p> http://www.k-wave.org/forum/topic/x-upward-shift-in-image#post-6590 Thu, 04 Oct 2018 14:43:15 +0000 Alexll7 6590@http://www.k-wave.org/forum/ <p>Hello !</p> <p>When I used a large transducer or/and when I simulated a large range of steering angles, I have always observed an x-upward shift on the reconstructed image compared to real medium (you can see here that the cylinder appears between 56.5 and 63.5mm instead of between 54.5 and 61.5mm : <a href="https://www.casimages.com/i/181004035409747281.png.html)" rel="nofollow">https://www.casimages.com/i/181004035409747281.png.html)</a>. For the reconstruction, I use "transducer.combine_sensor_data" (I use the C++ code on GPU so this stage is necessary) then "transducer.scan_line" and then your code "example_us_bmode_phased_array" starting from the line "t0_offset = round(length(input_signal) / 2) + (transducer.appended_zeros - transducer.beamforming_delays_offset);".<br /> After a lot of research, I observed that the output of combine_sensor_data has a significant negative temporal offset compared to the input (for example, the transducer_input_signal starts before in the output compared to the input). With an analyse of the source code, I find that, in line 908 (of kWaveTransducer.m), you use transducer.delays_mask(2) to obtain the elevation_delays. But, in transducer.delays_mask(2), there is also the transducer.beamforming_delays_offset. Because of that, in line 913, you apply again the transducer.beamforming_delays_offset to sensor_data... And this temporal offset causes the spatial offset observed in the images.<br /> There are 2 solutions to fix this, either change the line "t0_offset = round(length(input_signal) / 2) + (transducer.appended_zeros - transducer.beamforming_delays_offset)" to "t0_offset = round(length(input_signal) / 2) + (transducer.appended_zeros - 2*transducer.beamforming_delays_offset)" in post-processing or change the source code kWaveTransducer.m line 609 "dm = obj.delay_mask(2)" =&gt; "dm = obj.delay_mask(2)-obj.beamforming_delays_offset".<br /> Since this change, I have always observed the objects at the well depth (e.g : the same simulation with the correction <a href="https://www.casimages.com/i/18100403550733177.png.html)" rel="nofollow">https://www.casimages.com/i/18100403550733177.png.html)</a>.</p> <p>So, my question is, Do you think my analyse is correct or I misunderstand something and the x-upward shift comes from an other thing ?</p> <p>I thank you in advance for your answer. </p> <p>Best regards,</p> <p>Alexandre </p>