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.

Topics - sharkmelley

Pages: [1]
General / Odd behaviour of "Additive with Scaling"
« on: 2018 March 16 12:38:26 »
I was using ImageIntegration to stack some TIFF light frames with the default "Additive with Scaling" option for output, which is the recommended setting for integrating light frames.

There was quite a dramatic change in the colour balance - especially in the background light pollution.

Here's a single exposure:

Here's the stack:

I would expect the stack to look exactly like the single exposures but less noisy.

The documentation ( ) is not very clear on Output Normalization.  It indicates it is trying to match backgrounds somehow.  But the backgrounds of the exposures were already very well matched.

The solution is easy - set it to "No normalization".  But I would like to understand what is going on and whether or not it is intentional behaviour.

By the way, this was non-linear data, as you can see.  I don't know if that has anything to do with it.


General / PhotometricColorCalibration results look too green
« on: 2017 September 07 00:17:05 »
I've been playing with PhotometricColorCalibration for my (modified) DSLR images.  It's a great tool and so far has worked flawlessly.  It gives consistent white balance multipliers across multiple images.  Credit to the very hard work put in by its authors!

However I do have a question.  Although the results are consistent from image to image, I am finding that the resulting images subjectively look too green.  Similar comments have been made on the following Cloudy Nights thread:

It's not just subjective, I have an objective data point as well.  If I take a daylight image of a ColorChecker test chart then I know what white balance and camera colour matrix will render the test chart colours correctly.  But if I use the same white balance and colour matrix on an astro-image and feed that image into PhotometricColorCalibration using "G2V star" as the white reference then PCC gives me white multipliers of approx. [0.76, 1.00, 0.73] i.e. it boosts the green channel quite noticeably from an image I believed was already correctly colour balanced.

I'm curious to know what might be the explanation of this apparent discrepancy.


I hit a bizarre problem yesterday.  If I plug a USB memory stick into my Windows PC while Pixinsight 1.8.5. is running, an error dialog box appears with the title: "PixInsight.exe - No Disk"
and with the error text: "There is no disk in the drive.  Please insert a disk into drive \Device\Harddisk8\DR8"
The dialog box has buttons for Cancel, Try Again and Continue.

As I hit those buttons the dialog box messages change in the following sequence:
"There is no disk in the drive.  Please insert a disk into drive \Device\Harddisk7\DR7"
"There is no disk in the drive.  Please insert a disk into drive \Device\Harddisk6\DR6"
"There is no disk in the drive.  Please insert a disk into drive \Device\Harddisk5\DR5"

After that, the error dialog box disappears. 

It's just a minor problem but it's very odd behaviour


Bug Reports / V1.8.5 PCL Module no longer loads
« on: 2017 August 05 08:22:44 »
I wrote a PCL Module that worked fine with V1.8.4

After upgrading to V1.8.5 I find that the module will no longer install under Windows.  On the "Install Modules" dialog, I can search and find my module.  However, hitting the install button brings up an error dialog "PCL Win32 System Exception" with the following text: "At address 000007FEFCEAA06D with exception code C0000005 :
Access violation: invalid memory read operation at address 00000000000000D8"

Is there something I need to upgrade in order to build a compatible module?


I've written a PCL process that uses a NumericControl (i.e. combined slider/edit/label) but I've found that the slider doesn't respond to Keyboard up/down arrows nor to PgUp/PgDn.  But a bare Slider control responds just fine.

It appears to be a more general problem because the NumericControls in the BackgroundNeutralization and ColorCalibration processes don't respond to the keyboard either.  However the Slider controls (StdDev) in the Convolution process do respond even though NumericControls (shape, aspect ratio, rotation) do not.

I'm using Ripley on Windows 7.


General / Bayer Drizzle Issues?
« on: 2016 October 17 22:38:40 »
Are there any known issues with Bayer Drizzle?  I'm using it and finding no real difference in sharpness between the usual integrated image and the Bayer Drizzled image, which surprised me.  I'm using a Sony A7S on a Tak Epsilon (focal length 500mm) so there is plenty of potential for the Bayer Drizzle algorithm to make a difference.

I've used the both the BatchPreProcessing script and the BayerDrizzlePrep script and they give identical results but not perceptibly better than the usual integration.

So now I'm playing with some synthetic data, generating synthetic raws from a star filled image with added features such as single red, green and blue pixels, blocks of 2x2 red, green and blue etc.  In theory, just 4 of these synthetic raws (with single pixel offsets) should be sufficient for drizzle to provide an almost perfect replica of the original.  However I'm finding that in each of the 4 "subs", Drizzle is smearing each single coloured pixel into a block of 4.  This is not what I expected to see and might explain why Drizzled images look just as blurry as standard integrated images.  In fact the tests I've done so far indicate that the standard integration is actually doing a better job of reproducing my synthetic image than Drizzle. 

I can tidy up my 4 synthetic raws and make them available as a test example if that would be useful.


I've written a script for calculating DSLR sensor parameters i.e. gain, read noise and dark current profile over a sequence of dark frames.  It will calculate sky fog noise as well if (featureless) light frames are supplied to it.

I hope I've managed to attach a zip file containing the script.  The script should be placed in your PixInsight\src\scripts folder.  The code is probably not brilliantly written (I'm no JavaScript expert) but it does appear to work.

The output is written to the Process Console. Here is a result from a Sony A7S camera at a constant ambient  temperature of 20C:

DSLR Sensor Parameters v0.0.4
Camera: Sony ILCE-7S
ISO speed: 2500
Image Size: 4256 x 2848
Bias frames exposure time: 1/8000 sec
Flat frames exposure time: 1/4000 sec
Dark frames exposure time: 297 sec
Light frames exposure time: 302 sec
Gain per channel(e/ADU):   [ 1.626, 1.607, 1.608, 1.615 ]
ISO for unit gain:         [ 4066, 4018, 4019, 4039 ]
Read Noise(e):             [ 1.33, 1.33, 1.34, 1.33 ]
Dark Current (e/pixel/sec) [ 0.1143, 0.1102, 0.1099, 0.1132 ]
Dark Current (e/pixel/sec) [ 0.1216, 0.1168, 0.1175, 0.1218 ]
Dark Current (e/pixel/sec) [ 0.1281, 0.1239, 0.1238, 0.128 ]
...<snip> ...
Dark Current (e/pixel/sec) [ 0.1675, 0.1606, 0.1618, 0.1666 ]
Dark Current (e/pixel/sec) [ 0.1684, 0.1617, 0.1628, 0.1674 ]
Dark Current (e/pixel/sec) [ 0.1711, 0.164, 0.1639, 0.1683 ]

Noise estimates for 297sec exposure
Read Noise(e):             [ 1.33, 1.33, 1.34, 1.33 ]
Thermal Noise(e):          [ 7.13, 6.98, 6.98, 7.07 ]
Skyfog Noise(e):           [ 46.59, 50.87, 50.88, 37.52 ]

Mean values in ADU
Bias Frame 1: [128, 127.9, 127.9, 128 ]
Bias Frame 2: [128, 127.9, 127.9, 128 ]
Flat Frame 1: [850.6, 881.7, 882.1, 532 ]
Flat Frame 2: [831, 860.6, 861, 520.6 ]
Dark Frame 1: [ 126.9, 126.7, 126.9, 126.6 ]
Dark Frame 32: [ 126.6, 126.6, 126.7, 126.5 ]
Light Frame 1: [1367, 1641.5, 1642.1, 903.6 ]
Light Frame 2: [1479.4, 1787.2, 1787.6, 958.4 ]

DSLR Sensor Parameters v0.0.4 Completed.

The results are given for each of the 4 channels:  R, G1, G2, B

It's fairly straightforward to use (I hope!)
Pairs of raw bias frames and (unsaturated) raw flat frames must be supplied to calculate gain and read noise (in electrons)
To calculate dark current, a sequence of dark frames must be supplied (at least 2)
For skyfog, 2 light frames must be supplied (with the same exposure time as the darks)
All frames must have the same ISO.

The only issue at present is that if dark frames and bias frames are black clipped to zero (which is typical of Nikon behaviour) then the results will not be reliable.  Warnings are produced if black clipping or flat frame saturation is encountered.

The calculations use only the central 25% of the image in both width and height in order to avoid vignetting problems or amp glow effects near the edges.

Any suggestions are welcome!




I'm working on a script that calculates DSLR sensor parameters and reports on how dark current increases from exposure to exposure.

However, for this to work properly, it is essential that the raw files are loaded as Raw Bayer CFA monochrome.  I can't find any obvious way to do this if the user has already set a different option using DSLR_RAW in Format Explorer.  I'm using ImageWindow.Open to open the files but I can't find any way to specify the Format Hints referred to in this post:

The script output looks like this:

DSLR Sensor Parameters v0.0.1
Camera: Canon EOS 350D DIGITAL
ISO speed: 800
Image Size: 3474 x 2314
Bias frames exposure time: 1/4000 sec
Flat frames exposure time: 1/15 sec
Dark frames exposure time: 305 sec
Channel order:             [RGGB]
Gain per channel(e/ADU):   [ 1.151, 1.101, 1.113, 1.113 ]
ISO for unit gain:         [ 695, 727, 719, 719 ]
Read Noise(e):             [ 5.5, 5.28, 5.42, 5.47 ]
Dark Current (e/pixel/sec) [ 0.133, 0.1271, 0.1247, 0.1256 ]
Dark Current (e/pixel/sec) [ 0.1715, 0.1629, 0.1593, 0.1626 ]
Dark Current (e/pixel/sec) [ 0.2039, 0.1861, 0.2144, 0.1932 ]
Dark Current (e/pixel/sec) [ 0.2338, 0.2149, 0.2443, 0.2837 ]
Dark Current (e/pixel/sec) [ 0.2677, 0.2435, 0.2517, 0.2563 ]
Dark Current (e/pixel/sec) [ 0.2971, 0.2748, 0.2756, 0.3451 ]
Dark Current (e/pixel/sec) [ 0.3234, 0.3035, 0.3007, 0.3158 ]
Dark Current (e/pixel/sec) [ 0.3461, 0.3216, 0.3236, 0.3427 ]
Dark Current (e/pixel/sec) [ 0.368, 0.3433, 0.3447, 0.415 ]
Dark Current (e/pixel/sec) [ 0.391, 0.3665, 0.3663, 0.4315 ]

If it helps, I attach the script here (with txt suffix instead of js)



Is it possible in PJSR to watch a folder for any new image file that is dropped into it so it can then be opened and processed using, for example, AberrationInspector, FWHMEccentricity (or some variant).  The intention is that this would happen in a "hands free" continuous loop.

I'm looking at this in the context of collimating a scope and camera to speed up the process of making an adjustment then displaying the results.



Wish List / Scripting with Process Icons
« on: 2012 March 22 23:06:34 »

I have a script that runs a few processes in succession - some are "global context" processes and some are not.   The output files from one process become the input files to the next etc.  I did this because I couldn't put all the processes in a ProcessContainer to run them on multiple files - the ProcessContainer complained when trying to run a global context process.

Unfortunately it means the script has to set up lots of parameter values for the various processes.  What I would like to do instead is to pick up existing process icons (whose parameters I have already carefully set) and use the script to tell those processes which files to work on.   There may already be a way of doing this but I haven't found it!


General / Preprocess and stack while I sleep
« on: 2012 March 16 13:25:39 »
Hi all,

Another question - I already have a whole week of experience with my trial version of PixInsight  :D

Once I've finished an imaging session I like to set off my processing as a batch job and then go to bed.  When I wake up in the morning I have a stacked image (this works well with both IRIS and with DSS).

Following Harry Page's excellent video tutorial, I thought all I needed to do was to put ImageCalibration, Debayer, StarAlignment and ImageIntegration into a ProcessContainer.  I then put my raw files into a ImageContainer and dragged its blue triangle onto the bottom bar of the ProcessContainer.  It began to do its processing but I got error messages like "ImageCalibration can only be executed in the global context".

Am I doing something wrong  :-[


General / Problem with CosmeticCorrection hot pixel removal
« on: 2012 March 13 17:32:17 »
Hi all,

I'm totally new to PixInsight - though quite experienced with DSLR astro-image processing.  I'm currently playing with the trial version of PI having gone through Harry Page's tutorials.

I've noticed that curiously the Image Calibration process is missing the ability to perform hot pixel removal - maybe I'm missing something? I want to deal with hot pixels before debaying otherwise they become tiny coloured crosses after debaying. 

Anyway I discovered CosmeticCorrection v1.6.1 in the Utilities menu and decided to use this.   However, the whole image that I'm calibrating ends up being convolved with a kind of square operator!  It's as if the CosmeticCorrection process decides the whole image consists of hot (or dead) pixels.

The details of the CosmeticCorrection I'm performing is as follows:
The images I'm correcting are single channel TIFs in i16 Gray format (batch converted from Canon CR2 raw files)
The MasterDark is a single channel TIF in i16 Gray format - hot pixels are value 1, everywhere else is precisely 0 (at least that's how the cursor reports the values when I load the TIF in PI (without using a Screen Transfer Function).
Dead pixel threshold is set to 0.0 which gives a dead pixel count of 0 in the dialog
Hot pixel threshold is set to 1.0 which gives a hot pixel count of 157 in the dialog
"Amount" is set to 1.0 and CFA is ticked.

My guess is that the whole image is being treated as hot or dead pixels.

I suppose I could get around this by doing some kind of PixelMath instead but it wouldn't be that easy.

Any help appreciated!


Pages: [1]