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 ... 268
1
well when you have sensor artifacts like amp glows or if you are using a CCD with RBI preflash turned on, you can't use dark optimization. there's no way around that.

i don't use BPP regularly so someone else would have to chime in, but i think if you added some flat darks that BPP would try to use those to calibrate the flats. i think BPP does try to understand what the duration of the various darks loaded are and intelligently apply them. but not 100% sure.

rob

2
it's not a dumb question - DSLRs can be tricky.

i guess this all depends on how you have the RAW file handler module configured. if the image was debayered by the RAW module, then what you did is likely correct. however if the RAW file handler was set to open the CR2 file in raw mode, then the image was never debayered. check if the greyscale image seems to have a "screen door" look to it. if not, you are OK.

to do a batch process in PI you use the ImageContainer process, which is at the bottom of the Process menu. you load the input files into the ImageContainer gui and optionally set the output file name template and output directory. then you drag the triangle of ImageContainer to the desktop, creating a process icon.

ordinarily you'd configure your process to do what you want it to do, and then drag the triangle of that process to the desktop, producing another process icon. then you drag that process icon onto the ImageContainer process icon and away it goes.

however in this case the Image > Color Spaces > Convert to greyscale has no gui, so what you need to do is apply it to some random image open on your desktop, and then right-click the image and select "load history explorer". then, if you open the history explorer from the tab on the lower left of the screen, you'll see ConvertToGreyscale as the last step in the process history. you can click on the little icon in there and drag it to the desktop, then do what i described above. this trick works generally for all the PI menu options that have no GUI (invert, etc.)

having said all that, you can do astrometry from within PI. if you just use the ImageSolver script (after giving appropriate scale and location hints) your image will be annotated with WCS coordinates. the latest version of PI has a readout cursor which will read RA/DEC after an image has been solved this way.

rob



3
it may or may not - it depends on whether or not this particular sensor or camera downloads the image into RAM before it sends it to the USB interface.

if the imager or camera has some kind of ram buffer the cmos readout speed is probably the same regardless of usb2/usb3.

rob

4
General / Re: Dark File Woes from Altair Hypercam 183CProTec
« on: 2019 April 17 22:29:50 »
some cmos sensors do exhibit this weird starburst thing at the edge of the field - if it's in the darks that's what it is.

but there's no reason why it should not calibrate out, so in this case maybe it is a flare? impossible to know without seeing the darks.

rob

5
think about what bias and darks are and you will have your answer. how can an image taken where no light is allowed to reach the sensor be dependent on the optical train?

rob

6
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

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


8
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

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

rob

10
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

11
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.

12
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

13
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

14
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

15
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

Pages: [1] 2 3 ... 268