rmandelb
commented
11 years ago On Apr 11, 2013, at 6:29 AM, dkirkby notifications@github.com wrote:
I am trying to generate Scattered images from deep catalogs and running into two issues related to the large range of source magnitudes in my catalog. If I generate each postage stamp with stamp_size == size, then I get the correct results (except for some ringing in the tails - is there an accuracy parameter to control this?)
We have a number of parameters that determine accuracy, but for the version of the code on the master branch, they have to be changed by recompiling. We have a pull request in now ( https://github.com/GalSim-developers/GalSim/pull/385 ) for some work that made it possible to change the accuracy parameters on the fly, so that might be helpful for you eventually. I'm guessing it's one of the Fourier space params that is the issue here.
However, we also have a few open issues that are for investigating numerical accuracy, so we might adjust the defaults. if you have some specific code snippet that illustrates this ringing, I would be interested in seeing it, since it could help us make decisions about these defaults.
but this is very slow. It would obviously be smarter to use a different stamp size for each source, so I tried stamp_size = 0, but this truncates the flux at O(1e-3) of the peak flux, which means that the blending of the tails of bright objects with the cores of much fainter objects is not treated correctly.
As a short-term solution, you could call the draw command with the wmult keyword set to something larger than 1, so that GalSim will automatically decide on a size for each image and then increase its size by wmult. This leads to my feature request:
Could there be an automatic stamp sizing option that includes pixels down to a specified surface brightness (or pixel ADU) threshold? Interesting. Chihway mentioned that she had already run into some issues with this for extremely bright sources (which would be saturated stars) for which our "must contain x% of the flux" criterion is inadequate to represent most of the object. Of course, most users will not be trying to draw stars that would be saturated, but it's still an issue even for very bright galaxies.
In principle, I think what you're suggesting would be easy to code up - even easier than the current way of choosing an image size. I'm willing to do this, unless somebody else wants to do it or has another way to solve this issue that doesn't involve adding a new option.
Also, once the pull request I linked above gets merged into master, you will be able ot change the "x% of the flux" criterion for automatical image sizes on the fly, since it comes from the value of "alias_threshold".
Another related issue is that since automatic sizes might be even or odd, about half of my sources are rendered with a half pixel offset because of Issue #380.
Well, it would also be super easy to simply choose that good image sizes can be always even / always odd. But let's see what happens with #380. After calculating per-object sizes myself, I ran into a new issue:
I'll leave that for Mike (who might be busy at the DES meeting).
dkirkby
rmjarvis
I am trying to generate Scattered images from deep catalogs and running into two issues related to the large range of source magnitudes in my catalog. If I generate each postage stamp with stamp_size == size, then I get the correct results (except for some ringing in the tails - is there an accuracy parameter to control this?) but this is very slow. It would obviously be smarter to use a different stamp size for each source, so I tried stamp_size = 0, but this truncates the flux at O(1e-3) of the peak flux, which means that the blending of the tails of bright objects with the cores of much fainter objects is not treated correctly. This leads to my feature request:
Another related issue is that since automatic sizes might be even or odd, about half of my sources are rendered with a half pixel offset because of Issue #380.
After calculating per-object sizes myself, I ran into a new issue:
Specifically, the following snippet does not generate a syntax error but only uses the stamp size for the first object in the catalog:
As a workaround, I am now generating individual Single images with varying sizes that I then stack myself as a post processing step, instead of rendering directly to a Scattered image.