-
|
Hi all, The As far as I understand, this implies that each target light spot must be located at a discrete pixel position, meaning that sub-pixel target locations are not directly supported. For example, if I wanted to place a light point at a position such as (1.5, 2.5), I would need to increase the resolution (e.g. by a factor of two) so that this point coincides with a pixel rather than lying between pixels. Could you please clarify if this interpretation is correct? I ask this also in light of other hologram computation approaches (for example wavelet-based methods) that directly take spot positions as input rather than a pixelated target field. Thank you for your help, Amaro |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Hi @amarosanz , Your description is correct (though optimize itself does not take in Yes, for the discrete Fourier transform (DFT)-based implementation of holography, padding is the solution to improve resolution. There's a helper function Fortunately, we do have other hologram approaches implemented. If you're making a array of spots, you can use Best, |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! The Cheers, |
Beta Was this translation helpful? Give feedback.
Hi @amarosanz ,
Your description is correct (though optimize itself does not take in
target, insteadtargetis an argument for theHologramconstructor).Yes, for the discrete Fourier transform (DFT)-based implementation of holography, padding is the solution to improve resolution. There's a helper function
get_padded_shape()(link) to help with calculating the needed shape if you want to target some numeric resolution.Fortunately, we do have other hologram approaches implemented. If you're making a array of spots, you can use
CompressedSpotHologram(link). This accepts an array of floating-point coordinates, free from the grid (alongside other stuff too). Keep in mind that this is slow …