-
Notifications
You must be signed in to change notification settings - Fork 10
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Problem with edge effects? #17
Comments
No, I haven't seen that before. The sky image feels pretty simple and robust. You can try calling it separately to see if anything looks weird there. brightenough is just supposed to be >3 sigma; is it finding sources and then removing them, or is it failing to find them at all? If the latter, I worry about the weight image not being right (implying that there is much more noise than there actually is, so nothing gets found), or the PSF. If the former, I don't have any immediate guesses unfortunately. |
it's finding sources and then flagging them out: "210211 faint sources removed" |
Mmm, that's weird. The peak finding and image fitting do use slightly different sky images with different filtering scales. I can't immediately see why that would cause issues, but in principle if the one for the fit were way too large then all of the sources would appear to be faint and get thrown out. The source detection also uses a single PSF stamp while the fitting uses the appropriate stamp for each location, so if the one stamp that source detection used looked right and somehow all of the other stamps evaluated elsewhere had weird garbage in them, that would cause problems. I'd probably put a pdb.set_trace() around here |
Thanks, that gives some threads to follow. @andrew-saydjari seems to be tracking these down now too on a different data set of mine. @SpacialTree is contending with the problem on these data. |
Since you find the sources in the initial pass, I no longer think it's the weight map. The concept would have been that if you had the weight map units wrong or something, the code would think that no sources were significant, since the weights were saying that the image was much noisier than it was. |
Also re the weight map, if you look at the source sigmas from im*weight, the peak heights are exactly what you would expect. My money is on the psf model that was hacked to import the JWST PSF and that is where I am spending my debugging time on this issue atm. |
When I have things cleaned up, I will actually push to PR #16, but all of the problems seem to have come from that. A quick and dirty rewrite to (1) get the order of the nstamp axis versus spatial axes right and (2) avoid some absolutely insane broadcasting rules in photutils seems to have resolved the issue. Here is a quick dump of that code. @keflavich seems to think that (2) was introduced by some update in photutils. Thus, I will record that I am using version 1.9.0 of photutils.
The following is a demonstration of my success using crowdsource with this PSF model for a JWST image. Obviously, we could do better with some improvements to the nodeblend maskbit etc. But I really just want a source-based mask for CloudClean, so I will move on to that for now. |
OK, just reading this now, looks like all the change is in: # photutils seems to use column, row notation
# it returns something in (nstamps, row, col) shape
stamps = []
for i in range(len(col)):
stamps.append(self.psfgridmodel.evaluate(cols[:,:,i], rows[:,:,i], 1, col[i], row[i]))
stampsS = np.stack(stamps,axis=0)
stamps = np.transpose(stampsS,axes=(0,2,1)) This could be made slightly more efficient, but I want to understand if something broke under me or if I somehow got lucky previously. @andrew-saydjari your images look good, and that's a nice-looking sky model (except for the saturated stars, no surprise there). What parameters did you use in |
Thanks. I played around a lot this afternoon with noblend/sharp_maskbits, but ended up just accepting what is essentially just the default parameters. This is adding a few spurious sources to every real source, but I think that is because of the difference between the true and coadded PSF that you noted before, and not a crowdsource setting problem. It might be worth running that gaussian blur test again with this model. For now, I am generating my CloudCovErr mask by running like: out = fit_im(im_clean,psfmodel_py,weight=wt,dq=d_im,
ntilex=1, ntiley=1, refit_psf=false,psfderiv=true,fewstars=100,
maxstars=320000,verbose=true,threshold=5,
blendthreshu=0.2,psfvalsharpcutfac=0.7,psfsharpsat=0.7,miniter=2, maxiter=10); P.S. I ended up commenting out the last transpose for my work, but there is a transpose between julia/python so you should just confirm that for yourself (and I can hack the transpose in more on the julia side). P.P.S I tried the usual list comprehension python trick, and got no speedup. One could try preallocation/other usual performance tricks, because these fits are taking a long time. I don't have a good handle on if it is much longer than usual for this crowded of a field, but my feeling is yes. |
Yeah, I don't think nodeblend / sharp will help you much if the PSF is just wrong. I agree that if this is some kind of ~drizzled image I would start by convolving the PSF by an appropriate ~top hat, and then probably adjust the blendthreshold But, sorry, summarizing: we don't think there is any particular problem with edge effects, but the PSF implementation for Webb was doing something wonky and you've fixed that? |
Yeah, I think that's what @andrew-saydjari concluded. I haven't gotten to run any tests yet. But we can... relabel this issue, I suppose? |
I may try to convert it to a discussion. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
We have some images with awkward edges, like this:
that end up rejecting all of the found stars in the image as "too faint" at this stage:
crowdsource/crowdsource/crowdsource_base.py
Lines 916 to 921 in fc92330
There doesn't appear to be anything obviously wrong with the weights (they're zero where the data are zero outside the image footprint). However, I suspect a problem with the sky modeling. Zooming in on part of the sky model, we have a corner-like artifact:
Any idea how to suppress this?
The text was updated successfully, but these errors were encountered: