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 ... 9
As a sanity check, pick a single raw (.CR2) light, dark, flat and bias frame. Calibrate the raw light frame using the calibration frames as master frames with ImageIntegration, having the "Calibrate" option ticked only in the Master Dark and Master Flat section. Ensure that the Master Bias, Dark and Flat tickboxes on the left are all checked. No need to Evaluate Noise. Examine the calibrated light for vignetting and debayer it with the "Auto" Bayer Pattern setting. If things behave as expected then the problem may be somewhere in the generation of your master calibration frames. I've just tried this procedure using data obtained with my 550d and an f/2 lens (with considerable vignetting). I encourage you to read Bernd's guide. I see that I'm repeating what others have said earlier so I can't see how I can further assist you.

My guess is that you have mixed master calibration files from a version of PI using dcraw for DSLR raw file handling and a latest version which uses libraw. Remember that our DSLRs use proprietary file formats and the PI developers can't reinvent the wheel and reverse-engineer every proprietary raw file format existing out there. They have to use an external library for the task. I don't think the PI developers have changed a fairly stable and robust process like the ImageCalibration process.

Please read and Bernd's guide I posted earlier. He's much better than me on explaining the calibration procedure. If you are using a version of PI which uses libraw, you probably should redo your master calibration files.

General / Re: Help - What's wrong with my master light?
« on: 2020 January 23 01:08:36 »
Before I start downloading an 1.7 GB rar file, could you please be more specific about the problem you are facing?

General / Re: Image calibration with flats changed behaviour
« on: 2020 January 22 04:53:15 »
The raw file has an extra row (5202 x 3465) while your dark, flat and bias is  5202 x 3464. With the extra 1 row, ImageCalibration fails with an "Incompatible image geometry" error. That's why I cropped the first row from your raw CR2 file, then saved as xisf and proceeded calibrating the cropped light frame using the provided dark, flat and bias.

I'm under an older version of PI ( which uses dcraw for handling DSLR data.

General / Re: Image calibration with flats changed behaviour
« on: 2020 January 22 04:04:03 »
Only one row is missing. I cropped the top row in order to calibrate your light frame. I manually calibrated your (cropped) light frame with none of the tick boxes checked (no "calibrate" and no "optimize" in the Master Bias, Dark and Flat section of the ImageIntegration process) and the resulted image seems flat. You have probably accidentally ticked one of these tick boxes, thus the over-correction. I debayered the calibrated light using the GBRG Bayer pattern (as a consequence of the cropping). See the attached image (heavily compressed to comply with forum restrictions).

In summary:
  • The latest version of PI will properly handle camera raw files and no messing with cropping and compensating with a different Bayer Matrix setting is needed.
  • I am sorry to say that but proper acquisition of calibration data is a must. Everything else is a workaround, only used when no access to useful data is possible.

Cheers and clear skies!

General / Re: Image calibration with flats changed behaviour
« on: 2020 January 22 00:46:41 »
After a quick look at your files, here are my observations:

Your dark is zero-clipped. It contains a lot of zero values probably because you probably pre-calibrated your darks. Please read Bernd's guide: and also take a look at Vincent's tutorial:
Why are you cropping your frames (by 1 row of pixels)? This scares me a lot :surprised:

You are welcome, Steve,

The Convolution process can be saved as an icon like all processes by dragging the "triangle" of the process window. If you are getting the warning that "the current filter library is not writable", just save the filter library in a different .filter file in a convenient place, and not where PI is installed.

That's true. It is a blur filter. It can also be implemented as a Convolution filter:

Code: [Select]
KernelFilter {
   name { Blur (3) }
   coefficients {
       0.000000   1.000000   0.000000
       1.000000   4.000000   1.000000
       0.000000   1.000000   0.000000

This is faster, probably because the Convolution process uses FFT. Rob's PixelMath expression is equivalent, modulo edge (boundary) effects.

Thank you Edoardo, a long time ago, I had the same idea, but you have implemented it and created a tutorial about it! Kudos!

General / Re: Price
« on: 2019 December 28 11:21:58 »
It is absurd when people are accepting paying the price of PI for a counterweight set (probably built by fairies, who knows >:D) while complaining for the price of PI, ignoring the level of engineering involved for writing scientific software like PI.

General / Re: Weird Dark Halos in Mono Stacked image
« on: 2019 December 23 00:52:57 »
Without specific details and/or an image it's hard to guess what's going on. How does the bright stars look like if you integrate without using a pixel rejection algorithm? (Pixel Rejection (1) > No Rejection). Have you tried using a higher Sigma high value?

Bug Reports / Re: PixInsight 1.8.8-3 Released
« on: 2019 December 15 03:14:45 »
Yeah, I have this same problem. Real shame as so will 417 million other Windows 7 potential users.
In less than a month Microsoft will no longer provide security and support for Windows 7 rendering it a potential security risk for all of its users. So the problem is Microsoft here. Their next OS is Windows 8.1 which is worse than 10 and will also be decommissioned in three years from now. If you were a developer, would you invest your time and efforts supporting a dying OS?

I am also reading that people using an unsupported OS are trying to find a missing dll. This is a great security risk. What if a ransomware infects your system? How many man-hours of data collection will be lost then? I am not a Windows fanboy but considering the security threats, the next sane solution is upgrading your system or switching to Linux.

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.

Pages: [1] 2 3 ... 9