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 ... 255
General / Re: Blink and SubFrame Selector
« on: 2018 December 11 17:46:21 »
that's normal - you're seeing the offset from light pollution. after stacking you can use DBE to remove the gradient/offsets, or if the LP is really well behaved, just a histogram transformation can compensate for it.


General / Re: Adding a watermark to images?
« on: 2018 December 11 06:35:14 »
i don't think so... it's 'burned in' so to speak; the pixels underneath whatever was annotated have been overwritten with the text...


General / Re: Do I need to crop before integration ?
« on: 2018 December 09 07:57:43 »
i think for sure with respect to rejection, the way II is configured by default (like when resetting the process) 0 valued pixels are rejected in the outlier algorithms. i have to read the code to find out if the normalization process ignores 0-valued pixels though. the code is on github (search pcl imageintegration).

you are right that alignment is not lost if you apply the same crop to all registered images.

in all my years of doing AP i've never heard of someone pre-cropping their subs to eliminate registration artifacts, so i tend to think it's unnecessary, but just because everyone does something one way does not necessarily make it right...


General / Re: Background too light
« on: 2018 December 08 18:42:37 »
yes i don't see a problem here - after DBE and STF->HT and another small histogram tweak:

General / Re: Do I need to crop before integration ?
« on: 2018 December 08 16:57:31 »
no - i think ImageIntegration completely ignores black pixels when computing image statistics for integration.


General / Re: is there away to do this?
« on: 2018 December 07 00:17:25 »

General / Re: Correct PixInsight DSLR CR2 RAW Setting Question
« on: 2018 December 06 17:04:53 »
he'll either post in the thread or he won't - that's how it goes.

anyway color correction is not super difficult post integration; it's what everyone does. the problem is that even if you eliminate any color biases from the filter, you will probably have atmospheric/light pollution effects causing color shifts anyway. so those still have to be dealt with and doing color correction twice would be a waste of effort.

PI has excellent tools for color calibration including the newest one - PhotometricColorCalibration - which analyzes the stars in your image to white balance the image against known white references. but you can start with the more old-school flow of BackgroundNeutralization followed by ColorCalibration. more than likely you'll have to start with DBE or ABE on the integrated image to get rid of any light pollution gradients. there are many tutorials on the web describing these flows...


General / Re: Correct PixInsight DSLR CR2 RAW Setting Question
« on: 2018 December 06 06:21:49 »
shoot, i forgot that PI does not use dcraw anymore to import CR2 files.

honestly juan might have to answer this question. i looked thru the source code for the RAW file handler and i'm not totally sure how it interfaces with libRaw - i don't know what libRaw is going to do if you ask for CFA but also ask for a white balance to be applied. the answer is not in PI's source code.

i suppose you can find out if this works by setting some really extreme custom WB (like on an orange card) and then opening an image with and without that custom WB and see if you get something different when you debayer the CFA image PI gives you...

at any rate, usually the answer to this question is that you don't want/need to bother with custom white balances when using a DSLR for astrophotography but of course you might have some reason for wanting to do this.


General / Re: Correct PixInsight DSLR CR2 RAW Setting Question
« on: 2018 December 06 01:22:55 »
im not sure if white balance is applied when the image is kept in an undebayered state. can you post the command line that PI puts on the console when you open a CR2 with these settings?


New Scripts and Modules / Re: Subframe Selector PCL Module
« on: 2018 December 05 18:23:59 »
if i understand what is being done, the file is locked because SFS has it simultaneously open for reading and writing.

sounds like you'll have to write the files to another directory then move the files back to the original directory (thus overwriting the originals) by hand.

the script version of this tool might be reading the whole image into memory, closing the file, then writing the file from memory to disk. the SFS process i guess works differently. cameron would have to comment.


General / Re: Question about my Flats approach
« on: 2018 December 03 05:05:23 »
it's just that the histogram in BYE mimics what a canon DSLR would show back-of-camera, that is, it's a histogram of the image with default stretch / gamma curve. this may have been a conscious choice on guylain's part, since there's a rule of thumb in DSLR astrophotography that the back-of-camera histogram should be "well-detached" from the left side of the histogram graph axis when shooting lights. since people rely on that it makes sense for BYE to display that instead of the histogram of the linear image (which is what's important for flats.)

the pink cellophane is a good idea. it's not important that the flat be grey but it is important that no one channel is terribly underexposed.


General / Re: Question about my Flats approach
« on: 2018 December 01 21:48:20 »
i merged your two topics...

General / Re: Crashing
« on: 2018 November 30 21:30:31 »
one thing that sometimes comes up with laptops are blocked air vents/dusty air vents which hampers cooling. having said that most modern CPUs are pretty good about keeping themselves out of thermal shutdown, but maybe it still gets hot enough to cause computation errors...


General / Re: So are my stars saturated or not?
« on: 2018 November 30 21:28:54 »
yeah, thinking about it more the application of the flat during calibration probably changes the 0.25 saturation value to something else.

in essense i think the problem here is that the data needs to be rescaled channel-by-channel to make sure that all the saturated values are 1.0 before the images go thru the rest of the pipeline. i think because in the stacked frame these saturated values don't seem to be saturated anymore, strange things happen when stretching. "regular" stretches like HT tend to blow out bright structures, so that may end up masking the problem. something like ArcSinh/Masked Stretch is going to try its best to preserve the color and as far as those processes are concerned you have a legitimate image of something pink, since the values are nowhere near 1.0.

perhaps SGP's method of rescaling the data when captured as fits is actually a good idea - i have always frowned on it a bit because in essense it ties the camera to the software in a way that can't be undone... the data saved by SGP is less raw than the camera provides, and the scaling makes the fits files incompatible with CR2 files you might have captured with different software, meaning that once you collect lights modified in this manner you are obligated to capture your flats, bias and darks in the same way. but if saturated stars come out as 65535, that's probably a good thing.

you can debayer the raw CR2 with the debayer process if you want to see what happens next. BPP also uses the Debayer process behind the scenes, but of course it debayers the calibrated frames.


General / Re: So are my stars saturated or not?
« on: 2018 November 30 05:29:40 »
PI shouldn't. i guess that's why i was asking about SGP - because if you save as fits using SGP, they scale the data up to 16 bits. and i don't think it's just shifted up by two bits, i think they are using DCRAW's built-in scaling.

if this is an integrated image though perhaps the subframe weighting has caused the change in the 'saturated' value from the expected 0.25. maybe if you look at the calibrated subs you'll see 0.25 everywhere for those stars.


Pages: [1] 2 3 ... 255