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 - dld

Pages: [1] 2 3 ... 8
General / Re: BPP or do it manually ?
« on: 2019 December 03 10:18:35 »
Image integration - Pixel Rejection settings ? - I could use the default settings suggested in the tutorial but how can I tell if these particular settings end up actually introducing
more noise into the final integration, OR, loosing valuable data and I've not even realized it.

Hello Paul,

while I was typing this, Rob gave some good directions. For one longer answer take a look at the corresponding presentation from Jordi Gallego.

While I don't consider myself a great astrophotographer, the best general advice I can give is: assess your sources (how credible is the material you are referring to), study, and try to understand the math. Take it step-by-step and experiment. Pick a single light frame and see if calibration has removed most of the hot pixels, or if it has corrected for dust and vignetting. Avoid complicated workflows involving deconvolution or local normalization. And this is half of the journey. Astrophotography comprises of a highly technical part and an aesthetic part which I believe is even more difficult to conquer.

General / Re: BPP or do it manually ?
« on: 2019 December 02 02:16:58 »
I pre-process and integrate manually only for one reason: To assess human errors during acquisition of calibration and image data, to learn from them and try to correct them next time. A tedious process, but the skills and image quality improvements I have experienced, fully compensate for all of the burden.

Automation is useful when most factors are in control. Tracking, focusing, proper acquisition of flats, proper acquisition of darks/flat darks/bias, and correct usage of them during data reduction. In short, it is useful when you know your equipment and when you know how to reduce your data.

Unfortunately what I suspect is most people settle on automatic tools and let human errors or other problems haunt their integrated images for ever, without noticing. For me PI is more of a debugger which allows me to correct my mistakes during acquisition.

General / Re: Adding additional frames to an integrated image
« on: 2019 November 06 02:07:01 »
Or just let ImageIntegration with no rejection to integrate your images with the proper SNR-based weights. Note that since you have two integrated and registered images, enter each image twice because ImageIntegration requires at least three source images.

Try aligning the channels before stretching. If you still have problems with the saturated stars and the latest StarAlignment process, please have a look here:


First of all, what version of PI are you using? Are you trying to align stretched images? The norm is to use StarAlignment with linear images. Also I have noticed that you have some stars with flat profiles (saturated stars) and this may be another source of issues.


General / Re: What does RGB working space actually do?
« on: 2019 October 25 11:17:08 »
Thank you all for your answers, it seems that I have to study more but...

As far as I can understand, a properly integrated, background-corrected and color-calibrated (with PCC) linear image, obtained from properly reduced data should be observer-independent. Assume we want to perform a deconvolution operation on the luminance component of the image. The luminance component shouldn't be observer-independent i.e., obtained without making any assumptions on human vision and color perception?

How does RGBWorkingSpace coefficients enter in such operations during the linear stage? If the default coefficients are obtained from a standardized color perception model, we break the observer independence (because here enters the "average" observer). Is this desirable? Or it is unavoidable by the same definition of the term luminance, and the only way to standardize is to use the default/standardized RGBWorkingSpace settings?

If the above aren't obviously wrong, I'll dare to say that Juan probably has similar philosophical questions :P

Thank you again, especially Juan, given his limited time available!

General / Re: What does RGB working space actually do?
« on: 2019 October 25 08:52:00 »
Thanks Steve for asking this since I have a similar question:

Some people suggest setting the RGBWorkingSpace coefficients at equal values. Is this necessary? And if yes, when and why?

Clear skies,

Bug Reports / Re: Catalog Star Generator problem
« on: 2019 October 13 09:45:42 »
Hello Guillaume,

An easier way to do mosaics, without the need of an artificial star field, is by using the MosaicByCoordinates script. Platesolve each panel and use the script to register all the panels together. And then use the GradientMergeMosaic process for the seamless assembly of the registered panels.

Bug Reports / Re: Problem decoding Canon 60D RAW
« on: 2019 September 26 12:51:47 »
The file appears to be an mRAW file.

An older PI version reports the following:

Timestamp: Mon Sep 23 21:17:23 2019
Camera: Canon EOS 60D
ISO speed: 800
Shutter: 120.0 sec
Aperture: f/inf
Focal length: 50.0 mm
Embedded ICC profile: no
Number of raw images: 1
Thumb size:  5184 x 3456
Full size:   3888 x 2592
Image size:  3888 x 2592
Output size: 3888 x 2592
Raw colors: 3
Daylight multipliers: 2.280493 0.939530 1.270003
Camera multipliers: 2072.000000 1024.000000 1662.000000 1024.000000

Invoking: dcraw -4 -o 0 -r 1 1 1 1 -t 0 -k 0 -H 1
Decoding Canon EOS 60D file (3888x2592 pixels, ISO=800, Exposure=120.00s): done
Loading raw image: done

I can't debayer the image. Maybe the inconsistency between image size/thumb reported size causes the problems.

Consider using the full-size RAW file format while imaging.

Bug Reports / Re: PI Installation problem on Windows 7 and 8
« on: 2019 September 21 00:47:41 »
Excusez-moi, je ne parle pas fran├žais :sad:. Fin du support officielle pour Microsoft 7 et 8.1: 13 Janvier 2015 et 9 Janvier 2018:

So this is inevitable. If you still have a decent PC and you don't want to install Windows 10, consider Linux as an alternative OS.

General / Re: Masked stretch and big star appearance
« on: 2019 September 18 04:39:36 »

The tooltip over the Iterations setting of MaskedStrech suggests increasing the default number (100) of iterations in such cases. Does this work for you?

There is a slight chance that StarAlignment mistakenly picked hot pixels as stars. In that case the real stars will either average out or rejected by ImageIntegration. Use Blink to inspect your registered frames to see if you have badly aligned frames in your stack.

General / Re: Quantification of image noise, literature
« on: 2019 September 06 10:25:14 »

PixInsight developers usually refer at articles by Jean-Luc Starck (who's known for work on wavelets and sparsity). Richard Berry's "Handbook of Astronomical Image Processing" is another reference used by PI developers, but I might be wrong. Anyway, most of the articles at have "proper" references so maybe it's the best place to take a look for something relevant to your needs.

Image Processing Challenges / Re: Non Linear PostProcessing
« on: 2019 August 21 13:27:16 »
You are welcome Marc,

Imagine an empty chessboard and yourself ready for a chess game. At the top left corner you see a white square and right next to it a black. If you rotate the chessboard by 90 degrees, the top left square is now a white. In chess there is the convention (rule) that the board is placed so that a white square is in each player's near-right corner. Unfortunately we haven't any rule for the placement of the contents of a Bayer matrix into a file, and furthermore, we have three colors instead of two!

That's why it is important for the software reading such files to know where to start reading pixel values and what color to assign at each pixel.

Any kind of luck is welcome :D even beginner's luck! I am sure you'll obtain fine images with your gear! I wish you more luck and clear skies!


Image Processing Challenges / Re: Non Linear PostProcessing
« on: 2019 August 20 14:16:28 »
I agree with Gerald, GRBG seems to be the correct pattern. And yes the image is sharp, the camera seems fine, and I am jealous :laugh:. These discrepancies are due to how the various acquisition programs decide to arrange the pixel values into an array of numbers and then into a (FITS) file. 

PS: Take a good read at Rob's post at Cloudy Nights. I think Bernd has some nice posts somewhere in our forum explaining what's going on, but I can't find them at the moment.

Pages: [1] 2 3 ... 8