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

Pages: 1 [2] 3 4 ... 16
I have just released an update for PixInsight 1.8.6 on Linux, macOS and Windows with a new version of the RAW format support module. The new RAW module integrates LibRaw stable version 0.19.2, which has been released two days ago. See the official announcement on LibRaw's website for detailed information:

Note that this version fixes just a few bugs and security issues; it doesn't add support for new camera models. However, the latest Nikon Z6 and Z7, among other new camera models, were already supported in the previous version and are of course supported in this one too. Please let me know if you encounter problems decoding raw images acquired with these camera models.

Hi Juan,
I am having issues with reading raw files from my Nikon Z7, I've posted about this but no one seems to be assisting in the matter.

Steve and the comments at the bottom of give the impression that LibRaw version 0.19.2 does not yet support the Nikon Z7 but the later code snapshot 201903 does.


Quote from: niccoc1603
It's also odd that the Dark Frame 1 has a mean level of around 1065-1066 and Dark Frame 5 has a different mean level of around 1005-1006 whilst the bias frames have levels of 1081 -1086.  I don't have an explanation for that.  Anomalies like that can skew the statistics quite seriously.
There is an explanation for that
It's too technical for me to really understand

Thanks for that - it's interesting. I'll need to take time to read and digest it.  It certainly looks as if it complicates the problem of calculating the sensor parameters for cameras affected in this way.


Quote from: niccoc1603
Hi, thank you for the script, it works great

Would it be possible to add the possibility to select 12bit/14bit/16bit scale like in BasicCCDParameters

My CMOS camera is 12 bit and gain e/ADu here is returned in 16bit scale

Another question. Any ideas why Dark current values are so different for RGGB channels?

It's an interesting point about the 12/14/16 bit scale - I haven't previously seen the script used on a camera that is not a DSLR.  The digital values reported are the ones found when opening the raw file, so it could be that a dedicated astro-cam is working slightly differently since it is not using a DSLR raw format.  What file format is being used?

The variation in dark current is simply a question of statistics.  Those dark current levels are extremely low compared with an uncooled DSLR.  Slight statistical deviations in the calculated bias level or read noise level can lead to much greater variations in dark current.  You need to use much longer dark exposures (e.g. 400sec) to obtain more reliable results for dark current.

It's also odd that the Dark Frame 1 has a mean level of around 1065-1066 and Dark Frame 5 has a different mean level of around 1005-1006 whilst the bias frames have levels of 1081 -1086.  I don't have an explanation for that.  Anomalies like that can skew the statistics quite seriously.


USB3 allows for much faster downloads than USB2 with USB2 leading to amp glow in some camera models. I am not sure if this one is subject to that as well but it could be the cause. In any case, always try to shoot lights and darks using the same port.

Of course I could be wrong and this has nothing to do with the starburst.


It appears that there could be a difference between USB2 and USB3. ZWO mentions the difference between UBS2 and USB3 here:


Quote from: mcintyre_sj

Juan then recommended using DrizzleIntegration

The only recommended way to generate integrated color images from CFA raw data, be it data acquired with digital cameras or single-shot CCD cameras, is DrizzleIntegration.

Since DrizzleIntegration is the recommended workflow, i would like to know how it handles alignment with the raw CFA inputs?

In simple terms it works like this:
  • The frames must be debayered and star aligned to work out the positional offsets and/or rotations of each frame.
  • Once the DrizzleIntegration is given this offset/rotation information it uses only the raw CFA data to produce the final integrated frame.


Quote from: ngc1535

I am super confused by this thread (and the archived one). Is this simply a specular reflection from a bright star due to a shiny surface at the edge of the chip?

The star burst pattern is a feature of the sensor and is obvious in the darks as well as the lights.

Good examples are in this Cloudy Nights thread.

The OP needs to provide some example raw files otherwise it's not clear why calibration is apparently not working.


General / Re: Benchmark images different colors
« on: 2019 March 14 03:01:59 »
The JPG from your laptop has been saved with an embedded ProPhoto RGB colour profile.
The JPG from your desktop has an embedded SRGB colour profile.

That's the main reason they display very differently.

Maybe you are using different colour management settings: laptop vs desktop


General / Re: colour saturation: not satisfied enough
« on: 2019 March 10 17:06:41 »
Quote from: paolo speggiorin
OK Mark, so if I use RAW files how can I do White balance in Pixinsight?

ColorCalibration or PhotometricColorCalibration


General / Re: colour saturation: not satisfied enough
« on: 2019 March 10 13:19:56 »
Hi Paolo,

When I refer to white balance, I mean doing it within PixInsight.  It's because I always use raw data and the white balance that is set in camera has no effect on the raw data.

My real time night sky video shot with the Sony A7S is an exception to this.  For that video, the white balance used would have been in-camera.  To be honest I'm not sure which white balance I used.


General / Re: colour saturation: not satisfied enough
« on: 2019 March 10 05:32:28 »
The colours you see in a JPG come from the various steps that the raw converter implicitly applies:
  • White Balance
  • Camera specific colour correction matrix to XYZ space
  • Matrix conversion to Adobe RGB or sRGB colour space including white point adjustment (e.g. Bradford)
  • Gamma for Adobe RGB or sRGB colour space
  • Additional saturation
If you know the matrices, you can perform the same steps to your linear stacked data from BatchPreProcessing but most people don't do this.  You would need a reasonable background in colour science to obtain the matrices and apply them correctly.

However you can get reasonably close by doing the following:
  • White Balance
  • Background Neutralisation
  • Adjust highlight point using HistogramTransformation
  • Colour preserving stretch such as ArcsinhStretch
  • Colour saturation to taste

Currently it is your image stretching that is bleaching the colours.  For preserving colour, an alternative to ArcsinhStretch is MaskedStretch.


General / Re: Pixel Math If (Case or Switch statement)
« on: 2019 February 20 23:11:34 »

Here's another approach I've often used:

val+=iif( x()==0, 0.020749760758206493, 0);
val+=iif( x()==1, 0.02083269071095121, 0);
val+=iif( x()==2, 0.020591074008640423, 0);
val+=iif( x()==3, 0.020587894424854085, 0);
val+=iif( x()==4, 0.02125898032182231, 0);


General / Re: Nikon D7500 sensor parameters
« on: 2019 February 12 14:45:55 »
You didn't mention what ISO you used.

So it's difficult to know if the numbers make sense or not (since they vary according to ISO).


Why the surprise?  The gain seems to be a perfectly reasonable figure to me.

It's also broadly in line with the results at PhotonsToPhotos:


Your flat frames are saturated in the green channel.  That's your main problem.  The green channel is clipping at a value of 3651 which you can clearly see if you look at the histogram in the HistogramTransformation tool.

I didn't notice it earlier because I missed the fact that the camera is only 12bit. 


A couple of things I notice:

   1) You have a mixture of ISO 100 and 400.  That won't help.
   2) Your flats show significant vignetting.  You need to select a region of interest that is as flat as possible.


Pages: 1 [2] 3 4 ... 16