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 ... 274
General / Re: Debayering mystique
« on: 2019 July 16 21:11:31 »
check this link for some understanding of what is going on

in short, a CCD device is sensitive to wavelengths of light from the ultraviolet to the infrared. in order to produce a color image compatible with human vision, you need filters in front of the sensor to isolate the wavelengths of light that the eye is sensitive to. in a one-shot color camera, there is a permanent set of R,G,G and B filters arranged in the checkerboard pattern you see in the link above. copying only the pixels belonging to a certain filter to one plane of an RGB image is what debayering does.


not yet... the only module that exists right now is for windows. however there is a standalone program called starnet++ that runs on macosx. you need some familiarity with the osx command line to use it though.


there is a chance this is caused by apple's sub-optimal thermal design for these new macbooks. we've seen this before.

to rule that out, you can go to Edit > Global Preferences. when the global preferences window comes up, click on "Parallel Processing and Threads" in the left-hand side pane, and uncheck "Allow Using all available processors", then enter a number of processors which is less than the total number of threads your CPU supports. i think on that i9 there are no hyperthreads, so maybe put in 4 or 5 instead of 6, which is the total number of cores. after this, click the circular button at the bottom of the global preferences to apply your changes. if you're able to successfully run ImageIntegration a few times, the problem is probably thermal in nature.


Gallery / Re: 2019 Solar eclipse from Punta Colorada, Chile
« on: 2019 July 10 15:43:54 »
i will take a look at that paper. i did actually do something like what you are describing - filling in the moon with the color of the corona right behind the moon. maybe making the whole moon a single value was a mistake. it did reduce the dark ringing but i still ended up with bright ringing right at the edge of the moon. although, if i remember right this may have come from the processing i did on the moon itself, which might have benefitted from the same trick.


General / Re: best time to debayer?
« on: 2019 July 10 14:07:34 »
the reason to use bias frames is if you want to scale (or "optimize") your master dark.

the idea is this: the dark current in any sensor is a function of temperature and time. since we usually use cooled cameras, we can hold the temperature constant between the darks and the lights. it turns out the dark current is a linear function of time, so it is possible to linearly scale the dark before subtraction from the light, where the dark and light durations do not match. so for instance you might sometimes do 20 minute lights for narrowband and sometimes 10min lights for LRGB. you can make a dark out of 20 minute subs and then scale them to 10 minutes by multiplying them by 0.5 before subtraction, instead of maintaining two separate master darks.

but there is a problem - the bias signal is not a function of time. so if you want to scale your dark, first you have to subtract the bias signal, and then scale the dark. if you don't do this, the calibration will be completely wrong. so when optimizing darks you either have to load a master bias and tell PI to both calibrate and optimize the dark, or you need to make a master dark which has the bias signal pre-subtracted. in that case you *always* need to load the master bias (whether or not you optimize the dark) since the bias signal is missing from the master dark. in this case you need to be sure to never check "calibrate dark" as that will amount to a double bias subtraction, which is also bad.

as an aside, PI doesn't actually care about the dark or light durations. what it does is iteratively scale the dark by calibrating a small portion of the light with different dark scaling factors and choosing the scaling factor that minimizes the noise in the calibrated result.

as a 2nd aside, this generally works for dedicated astro cameras. DSLRs play all sorts of dark current suppression tricks in the camera firmware and these tricks can not be turned off. so sometimes dark optimization does not work well for DSLRs.


Gallery / Re: 2019 Solar eclipse from Punta Colorada, Chile
« on: 2019 July 10 10:26:22 »
OK i'm glad to hear that the trouble i had wasn't "just me".

the large scale/small scale stuff seems very important. in my own images there is a huge low-frequency "halo" around the sun that i had trouble removing. when you look at images from druckmuller, these large-scale components are entirely gone. but i understand he and his team have developed lots of code for processing eclipse images so i am not surprised.

in my own efforts i also ended up with a sort of ringing artifact around the moon which was undoubtedly caused by HDR compression, but my efforts to supress it were not successful. i have been meaning to go back and try again but frankly it is a lot of work!


Gallery / Re: 2019 Solar eclipse from Punta Colorada, Chile
« on: 2019 July 09 22:47:38 »
are there any background stars in your image? for the 2017 eclipse many of the brighter stars in leo were visible. regulus was especially apparent so i was able to use DynamicAlignment to hand-align my frames. automatic methods tend to fail (FFTRegistration) since they tend to latch on to the moon's shadow and so you get a moon-aligned image.

carlos, that is a great image. did you have any problem with the overexposed areas in the HDR merge? i had a lot of posterization in my 2017 merge which i think may have been caused by the 14-bit data from the camera not filling up the entire i16 space... in other words similar to the "pink stars" problem you sometimes see with DSLRs. in the end i had to split the channels before doing the HDR merges to prevent the posterization.


for any integrated image you should use a 32bit sample format. xisf is superior to fits in a lot of ways and is the native filetype for pixinsight, so it makes sense to use xisf.


General / Re: RAW Modules Does Not Product DSLR Color Images
« on: 2019 July 06 11:55:49 »
what was the problem?

open the global preferences process, click on the directories and network section, and then specify one or more directories where you want to store swap files. then when done, click the global apply button (the circular button at the bottom of the window.)

the system temporary folder(s) is a totally rational place to store files, but over the years it was discovered that sometimes windows (and macosx) will clean out these directories automatically, thus preventing you from saving your projects. so juan added this warning so that you will know you are at risk of this happening.


General / Re: Empty Image? Not so much.
« on: 2019 July 04 14:01:38 »
yep, changing the gain and or camera drivers will probably lead to problems like this. can you re-take the calibration frames using the same gain/driver as the new lights? (just a handful would work to test this)


General / Re: Empty Image? Not so much.
« on: 2019 July 04 09:09:18 »
there is probably some problem with your master dark. check if the background level in the dark is higher than the light. also check the dark to make sure it has higher levels than the bias.


General / Re: Removing Noise from an Image
« on: 2019 July 03 17:21:26 »
on #2 i can't say exactly, i mean as i mentioned it is possible subs from later in the evening are worse, either due to camera noise increasing, or maybe shooting into a light dome on that side of the meridian, or even clouds that moved in over time...

on #3 all BPP does is to call the individual processes in turn, handing all the file naming and propagating the name of the reference frame along as it morphs (-> calibrated -> debayered, etc.) obviously you have more control over everything if you do it manually but the BPP defaults for StarAlignment for instance are pretty sane. it's really just the ImageIntegration step that juan recommends that you do by hand so you can tweak the rejection method and parameters, since every stack is different...

#4 yes you can just integrate the stacks, but since ImageIntegration wants a minimum of 3 input files, what you have to do is add both files twice. the result will be mathematically the same as though you were able to integrate just the two files. normally when you integrate stacks together you turn off pixel rejection since 1) each stack should, if comprised of enough input images, already be free of outlier pixels and 2) generally you only have a handful of stacks and so pixel rejection is difficult or impossible when you don't have enough input images.


General / Re: Removing Noise from an Image
« on: 2019 July 03 16:38:42 »
well the % is just the percentage of pixels that were analyzed as contributing to noise. pixels with strong signal are excluded so this tool tends to measure the noise in the background, unless it is restricted to high SNR areas using a preview.

the leading number is the standard deviation of the pixels under consideration and smaller numbers are better. as you can see, the registered image actually has lower noise than the unregistered image. this is because registration involves interpolation, which involves averaging neighboring pixels together... and that boosts the SNR of a given pixel.

anyway, armed with this tool you should be able to go thru some subs from each side of the meridian and find out if one side truly has worse SNR than the other. or, you can make two integrations from equal numbers of east subs and west subs, and see how the noise looks in each stack. however, i'm not sure that this script is going to tell you if there are a bunch of hot pixels hanging around, which actually seems to be the main problem in your image.

anyway i feel that all this "upside down image" stuff is a diversion. i think there is a very narrow set of circumstances where PI could read in the calibration frames upside-down with respect to the light frames, and since you are exclusively using CR2 files with 'pure raw' this should not ever happen. note that just because the image is sometimes formed upside-down on the sensor does not imply that the sensor data has been read in upside-down.

i think you first have to definitively determine if the subs from one side of the meridian are truly worse than the other side, and if not, then start looking at why there are so many hot red pixels in your images. it could be simply down to dark scaling during calibration; any time a master dark is scaled, you risk under-correction of hot pixels. of course you can clean this up with CosmeticCorrection. or it could have to do with the camera being hotter for later subs than it was for earlier subs which increases the dark current (and the associated dark noise) in the sensor.


General / Re: Removing Noise from an Image
« on: 2019 July 03 14:54:46 »
you are comparing a bayered image (_c) with a debayered image (c_d_r). these can not be correlated with one another... you need to compare the calibrated, debayered, unregistered image (c_d) with the calibrated, debayered and registered image (c_d_r)


Pages: [1] 2 3 ... 274