Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - pfile

Pages: 1 2 [3] 4 5 ... 270
31
General / Re: Noise reduction for luminance masks
« on: 2019 April 08 09:25:02 »
yes i think it is a common technique to smooth your mask a bit for this purpose. since the low SNR areas of your image are (by definition) noisy, the mask is also noisy in those areas which leads to a kind of an uneven noise reduction when applied thru such a mask.

i usually use atrous to remove 1-3 wavelets from the mask, depending on how noisy the mask seems to be.

rob

32
General / Re: Mass change pixel values
« on: 2019 April 08 09:22:27 »
iif ($T==0.001,0.0011,$T)


33
General / Re: advice on processing RGB
« on: 2019 April 04 10:53:32 »
you can get a preview of what the image will look like by unlinking the channels in the STF process (the chain link icon) and then computing a new STF for the image. the blue cast should go away.

the way to solve this is to use BackgroundNeutralization to make the background of the image grey, and then performing ColorCalibration. then if you re-link the channels in STF and recompute, the image should look (and be) right.

an alternative to BN/CC is to use PhotometricColorCalibration.

i don't think you need to do anything special with the RGB working space just to combine your masters.

rob

34
hi - the advice you are getting on CN is good; probably no need for me to go into this here.

rob

35
General / Re: Flats creating orange background
« on: 2019 April 02 21:39:22 »
BackgroundNeutralization is what niall meant... it is a process. set the thresholds just above the highest values you measure in the background.

rob

36
General / Re: Newbie amazement... and frustration
« on: 2019 April 02 17:46:14 »
with all the new astrometry stuff in PI it seems like one could even generate a star mask from PPMXL, but i guess you'd have to do some optics modeling to come up with the right FWHM, and impose magnitude limits.

rob

p.s. a couple of other star mask ideas - you can try AdvStarmask.js from https://www.skypixels.at/pixinsight_scripts.html. also one technique is to somehow generate a starless image and take the difference between the original and starless image to get an image of just the stars. additionaly the python version of starnet produces a star mask image.

37
General / Re: Flats Fail to Correct Luminance
« on: 2019 April 02 12:16:43 »
maybe your twilight flats were just too dim and have lessened the SNR of the calibrated result too much?

twilight flats are kind of a pain to do right; there is a spot in the evening/morning sky that is as gradient-free as possible. it does move as the sun goes down. software like ACP will compute where this is and automatically point/repoint the telescope (and adjust the exposure as the sky brightness changes.) if you have to do these flats without automation, you need to babysit them and try to point to the right place in the sky as well as steadily increase the exposure (for twilight flats of course.)

anyway to adam's point, the idea is to illuminate the sensor as closely as possible during flat acquisition as during light acquisition. to that end the night-sky flats might be more accurate (and easier to do.)

rob

38
General / Re: Windows 8.1 and PixInsight Incompatibility
« on: 2019 April 01 16:15:06 »
well that was just a known forinstance... just didnt want the quicktime thing hanging out there cause thats not what QT stands for in PIs context.

rob

39
General / Re: Flats Fail to Correct Luminance
« on: 2019 April 01 09:03:59 »
i don't have a solution necessarily, but every rig i've built which uses a correcting element, both refractor and reflector, has suffered from this problem.

is it easy to try removing the corrector and see what you get?

i suppose you might also try twilight sky flats with no t-shirt to see if this helps any.

beyond that i guess you need to look for anything in the optical path that might be reflective in even the slightest way.

rob

40
ok - yeah, those are SBIG's proposed extensions to the FITS header keywords. i don't think PI considers those keywords - no mention of them from grepping thru the strings in the FITS handler module, and no mention in the BatchPreProcessing source. further, it seems that all files in BPP are opened with the same format hints, which contain either up-bottom or bottom-up depending on the switch in the GUI. but that's just from casual inspection of the code. i didn't try to add debug printfs or anything to really check that for certain.

rob

41
what keyword is used to indicate the origin? i don't think PI considers it, whatever it is. most FITS keywords are non-standard...

rob

42
General / Re: Ha Calibration Woes . . .
« on: 2019 March 28 21:53:49 »
i guess all that's left is the SBIG drivers/firmware... but yeah i don't think the FLIPPED thing is necessarily related. i guess it could be if the SBIG driver suddenly started writing out the images with the opposite direction, but since this particular problem with the darks seems to have manifested just the other day it's probably not related to whatever change happened in 2016.

rob

43
General / Re: Ha Calibration Woes . . .
« on: 2019 March 28 11:07:18 »
do you have darks and lights taken with very old versions of SGP that you can compare with the newer ones? you should be able to tell if the older darks are rotated/flipped/whatever vs. the newer ones by looking at the column defects/gradients. i think the version number of SGP is written into the fits header, so you can know that definitively without guessing based on when the frames were acquired.

since the FLIPPED=T thing seems to be related to platesolving, did you happen to change platesolvers in SGP recently?

rob



44
hmm... the thing is as long as all the types of frames are processed with the same fits reader direction, things should work out right calibration-wise (but as you say the images will be upside down if the wrong reader direction is specified)

this is pretty strange.

rob

45
Image Processing Challenges / Re: Flats, reflection issues
« on: 2019 March 27 16:50:57 »
well this wasn't so much about the corrector occluding the mirror as much as it was reflections incident off of the front edge of the corrector... if light can see the edge of the corrector then it can bounce off of it. anyway if you can swing it you might try making sure the front of the corrector is flocked and/or blackened somehow.

rob

Pages: 1 2 [3] 4 5 ... 270