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 ... 268 269 [270] 271 272 ... 277
General / Re: Question about image streaks
« on: 2011 January 29 18:30:41 »
hi sander, yah, that's my name, don't call me late for dinner!  8)

astropixel - what stacking method are you using? in general making the 'sigma' values lower rejects more pixels from the stack. you can experiment with different values reasonably quickly after the first time you've done an integration. just tell ImageIntegration to work over a small but interesting 'region of interest'.

General / Re: Question about image streaks
« on: 2011 January 29 16:41:09 »
it would not be the first time that i've misunderstood something, but... isnt the fact that the mount is drifting very similar to having done dithering on purpose? (aside from any oval stars that might result from the drift...)

in other words, the streaks are actually a good thing in the sense that those hot pixels are not stacking right on top of one another, and could be rejected by tweaking the stacking parameters... right?

still yes, it could be that the calibration was a bit off in the first place, leading to excessive dark or bias noise being left in the calibrated frame.

Bug Reports / Re: Bug in GreyCStoration
« on: 2011 January 26 20:23:24 »
by the way, i have found that attaching gdb to the pixinsight process and then telling it to return from whatever frame it's in (sometimes a few times, until PI stops segfaulting) can sometimes get PI back into shape long enough to save my work and then exit the app... this has saved my life at least twice.

this is pretty easy on macosx, not sure about windows though. maybe there is a microsoft debugger that is easy to install.

Bug Reports / Re: overscaling of darks on DSLR data
« on: 2011 January 26 18:40:58 »
just to add a little more here, the subs that seem to be giving me trouble have exif temperatures at 17C. i think on that night i did not start my cooler because the humidity was very high. the dark subs, however, were taken with the cooler running and have an average temperature of about 13C. the dark subs were taken within a few days of all the lights, so i don't think this is a case of the sensor characteristics changing with time. unfortunately my cooling setup is not robust enough to dial in a particular temperature, so i'm not sure if i can come up with a master dark that exactly matches these lights.

so PI is clearly doing the right thing, as the master dark does need to be scaled.  the hot pixels that are problematic seem to be brighter in the master dark than they are in the uncalibrated light. so this might just be a case of the master dark not really matching the lights.

the screenshot shows one particular area where a few hot pixels have been oversubtracted. for comparison there's a calibrated light with no dark scaling, and the uncalibrated light.

here are 2 lights; IMG_0011 causes the dark to get scaled by 1.7x and IMG_0014 somewhat less (like 1.2) these seem to correlate with the exif temperature.

here are my calibration masters:

Bug Reports / Re: overscaling of darks on DSLR data
« on: 2011 January 26 12:58:45 »
well, i made sure to check that box, and i remade all my masters and then did the calibration again.  the result is much the same. in fact this time, some of the lights were even scaled as high as 1.7x. i'm starting to wonder if this has something to do with the DSP tricks that canon uses to reduce dark current, since the exposure is so long. of course i've turned off everything that i can in this regard but i have read that regardless the DSP is still doing something behind the scenes. anyway i'll post the files somewhere and maybe a screenshot showing what i'm talking about, though it is obvious - there's black pixels all over the brighter parts of the image.

Bug Reports / Re: overscaling of darks on DSLR data
« on: 2011 January 26 08:02:55 »
i think i may have forgotten to tick the 'no black point compensation' - i'll re-do everything and try it again.

by failing i was talking about the message regarding failure of MRS noise evaluation...

the moon is probably bright enough that "traditional" tools may work well. have you looked at enfuse and align_image_stack?

Bug Reports / Re: Iconize screen redraw problem on a Mac
« on: 2011 January 24 21:26:52 »
yeah that's true, i'm running 64-bit PI. i guess i knew about the UI weirdness, but i suppose i didnt expect it to be so crashy. i guess i'll use the 64-bit version to stack and go back to 32-bits for everything else until this is sorted out.

Bug Reports / overscaling of darks on DSLR data
« on: 2011 January 24 14:07:41 »
i know we've discussed how sometimes multiscale noise eval fails on DSLR images. if there is trouble with the noise evaluation, i can see how dark scaling could go wrong. i don't see any messages about that in this case however.

i've got 30 minute Ha lights which are being calibrated with a master dark made from 25 30-minute dark subframes. the master bias also has 25 frames.

on some of the lights, the dark is scaled by ~0.95 or so, which is fine and probably expected due to temperature differences between the lights and the master dark (3-4C). however, on some of the lights, pixinsight scales the dark frame by 1.5 and the resulting calibrated frames have black pixels punched out of them, in some places where there is a lot of signal.

should i package these and upload them somewhere? it's likely to be user error of some sort or other, but i thought i'd ask.


Bug Reports / Re: Iconize screen redraw problem on a Mac
« on: 2011 January 23 10:22:43 »
i get this too, seems to happen a lot when you hover the mouse over the workspace icons and it generates a preview. when you hover away, a white square is left in the place of the preview. that white square will not go away. usually this means that in 15-20 minutes pixinsight is going to coredump.

@sander thanks. i'll be calibrating the frames with PI anyway so i'll have CFA fits files, so i guess the raw thing does not matter too much.

@simon i should read that script and see if it's doing anything special.

if i shoot with a Ha filter, then of course some light leaks into the G and B channels.

it would seem that you want to get rid of the G and B channels. however, debayering and then throwing away the G and B channels is probably wrong, because you've 'polluted' your red pixels with noisy data from the G and B channels during interpolation (right?)

so how do you extract just the R channel out of the CR2 file (or the calibrated .fits file) if it is in CFA format, and make it a monochrome image? if i understand this right i will end up with an image that is only 1/4 the size of the advertised sensor size, but it will be 'pure' red data.


Bug Reports / Re: osx x86_64: pixelmath gui behavior
« on: 2011 January 18 22:07:12 »
i should add that this only happens if i directly type the equation into the K/RGB box, rather than constructing it with the view/function explorer thing.

Off-topic / Re: Calibration and Stacking Help
« on: 2011 January 18 08:52:08 »
i'm not sure if it makes sense to integrate all the darks together... i'd keep them separate and then just use the dark that's closest to the length of the lights you are calibrating.

That's an interesting point. I took this to also mean that the combination of darks may vary in exposure times. Combining a set of darks with a sum of 1000 seconds (by way of example) may involve combining different exposure lengths. Correct me if I'm wrong, but I don't think it matters. :) I presume that is the case for darks to lights also.

Don't worry if your master dark has 1000 seconds of exposure and your flat frame is only 10 seconds: IC will multiply the thermal noise of the master dark by 0.01.

i took that to mean that the dark subexposures are 1000s each, and that the master dark is composed of some unknown number of them. 1000s is only 16.67 minutes, which is more like the length of a single subexposure than the sum total of all the exposures in a stack.

Thanks for your comments guys.

I didn't mention but my lights are at different exposures to. I have

Lights 6x600secs, 10x300secs, 20x120 secs and 15x60secs
Darks 10x600secs, 10x300secs, 10x120secs and 10x60secs
Flats 20
No bias.

I want to calibrate and stack in Pix. Are you suggesting that I stack and calibrate each different exposure to end up with 4 images then integrate them together to get the final image? I feel the need for a tutorial :D

Thanks for the continued help......I really need it.

okay, first off, you have to use a master bias frame if you expect to scale the master dark. the bias noise is fixed in every kind of frame, and if you don't remove it from the master dark, when you scale the master dark, you will also scale the bias noise. this will end up over or under-subtracting the bias noise from your lights.

also, it's hard to tell from a single line in a forum post, but you might have the flow backwards. first you calibrate each light frame with your calibration masters. then you register and stack the calibrated lights. but you should only stack together lights of the same duration, so yes, you should end up with 4 stacks. if you register each subexposure against the same reference image, then the stacks should already be aligned to each other, so you can then go right into HDRComposition and merge together your 4 exposure lengths. then carry on with normal processing.

It is my understanding that you can integrate all your darks and create a single master - same for bias and flats.

I probably conflict with pfile here, but as the master is a master, I think it is intended to be an integration of all the darks and through scaling is representative of all the lights (if that makes sense). Happy to recant if I'm wrong about this.

You can integrate individual time sets, with HDRComposition for instance if you want to reveal detail - e.g., M42.

the goal of integrating any image is to reduce the uncertainty of the value of a given pixel as much as possible. this goes for signal as well as 'noise' caused by dark current or bias current. if your subexposures have different lengths, then the value of a given pixel is going to have multiple distributions around different mean values. therefore there is no one true mean value for a given pixel to 'home in' on, and so your pixel value does not converge properly. i've always interpreted this to mean that your subexposures should have the same exposure time, whether they are darks or flats or lights. during calibration, PI is scaling the master dark to remove the dark noise from the light subexposure under consideration, to compensate for the master dark being at a different temperature or subexposure length than the light. but that's okay because if the master dark is 'clean' (meaning the uncertainty of the pixel values is low because you have used many dark subexposures to come up with the master dark), then you can come up with a linear scaling value for the dark before subtracting it from the light.

Off-topic / Re: Calibration and Stacking Help
« on: 2011 January 17 11:19:43 »
pixinsight scales the dark frame to match the frame under calibration by analyzing the noise in the target frame. i've had pretty good luck with a set of master darks made from subs of 4 minutes at 11-15C, average 13C against lights that were captured from 2C to 15C. also i've used the same master dark with 8 minute and 30 minute exposures. not sure if 30 minutes is really such a good idea, but i have not had time to make new darks.

juan or vincent would have to comment about how wide of a temperature/exposure length range a given master dark should be scaled. when using a CCD camera, the temperature is usually well controlled and so the variable quantity is time. with a DSLR your sensor temperature is going to vary quite a bit depending on ambient conditions and whether or not you have some kind of cooling solution. my cooling solution is bad and so my sensor temperature ends up being about the same as the ambient temperature - no control. either way though, noise is noise so PI probably does not care if the calibrated frame is hotter/colder or longer/shorter than the dark when computing the scaling factor.

i'm not sure if it makes sense to integrate all the darks together... i'd keep them separate and then just use the dark that's closest to the length of the lights you are calibrating.

anyway, in answer to your original question, the exposure length of your flats is probably pretty short compared to a light, right? pixinsight is going to have to scale whatever dark you use, so you might as well use the 60s master dark to calibrate the flats.

Pages: 1 ... 268 269 [270] 271 272 ... 277