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 ... 15
1
General / Re: Why does WBPP use ConvertToGrayscale?
« on: 2019 November 26 16:07:41 »
Quote from: warden
Examining the histogram shows that the red and blue histograms overlap exactly, with the green histogram slightly (but noticeably) displaced from them. The individual debayered images show similar histograms.

This is exactly what happens when the wrong Bayer Mosaic pattern is used.  That may (or may not) be the cause here.  By the way, which camera are you using?

Mark

2
General / Re: Pink stars after integration - DSLR data
« on: 2019 November 11 11:01:37 »
White balance is the usual reason for the saturated parts of stars turning pink.  In the raw file, the Red, Green and Blue channels will all have the identical saturated values.  White balancing boosts the red and green channels turning those saturated parts to pink.

Mark

3
General / Re: Flat Field Problem Over Correcting
« on: 2019 November 03 02:54:14 »
Are your light frames taken with the same dew shield as the flat frames?  They need to be.

Mark

4
General / Re: TIFF bit depth
« on: 2019 October 19 03:44:46 »
Be aware that 32bit mode in Photoshop is a special linear mode.  It behaves very differently to 16bit and 8bit modes.  Photoshop assumes that 32bit data is linear and therefore applies a gamma transformation to the data which it does not apply for 16bit and 8bit data.  This is why opening a 32bit file in PS looks quite different to opening the equivalent 16bit file.  The issue is with Photoshop and not with PixInsight.

To get overcome this issue you need to perform some complicated operations with bespoke embedded ICC profiles and/or pre-transform your 32bit data.

Mark

5
General / Re: PixelMath question
« on: 2019 October 18 16:40:14 »
Quote from: CraigNZ
Further research into this shows the problem is with division.  For example, this equation

$T/1.0

works okay, every pixel is the same as before,

but this equation

$T / $T

changes every pixel to 65535 (unsigned 16 bit integer formatting)

it should have been 1 for each pixel (e.g., 100 / 100 = 1)

There's no problem there.  PixInsight natively works with floating point numbers in the range 0.0-1.0
But if you choose to display the pixel values as 16 bit integers then they will be displayed in the range 0-65535
You could equally choose to display them as 8 bit integers in the range 0-255

The answer to your original question:
y = 0.99 *x + 140/x + 318.0
depends on the range of values that your version of x is allowed to take.

I'm guessing your x is in the range 0-65535 and your constants are compatible with the same range, then the PixelMath formula you want is:

(0.99*($T*65535)+140/($T*65535) + 318)/65535

This is because PixelMath values of x are natively in the range 0.0-1.0 and the result of the expression needs to be in the same range.

Mark

6
Bug Reports / Re: 1.8.7 Debayer not working in BPP
« on: 2019 October 10 09:19:53 »
Look at the names of your .cr2 raw files

e.g.
Calibrating target frame 23 of 29
Loading target frame:
E:/Astrophotography/AP RAW Data/M045/2019-10-03/M045_LIGHT_180.00s_1600.00iso_2019-10-04_23 .cr2

There's a space between the "2019-10-04_23" and the ".cr2".  It's not good practice to have a space there but I guess it's done by your acquisition software.
If you rename all your .cr2 raw files to remove the trailing spaces then BPP should work fine.

Mark

7
Bug Reports / Re: 1.8.7 Debayer not working in BPP
« on: 2019 October 10 01:08:46 »
Looking at your log file:

CosmeticCorrection is writing a file named like this:
M045_LIGHT_180.00s_1600.00iso_2019-10-04_01_c_cc.xisf

Debayer is failing to find a file named like this:
M045_LIGHT_180.00s_1600.00iso_2019-10-04_01 _c_cc.xisf

Note the additional space character in the name of the file that can't be found.  The file can't be found because it doesn't exist.

I'm simply pointing out the obvious but I don't have any explanation for how this could happen in BPP. 

Mark


8
Bug Reports / Re: Problem decoding Canon 60D RAW
« on: 2019 September 27 03:50:46 »
If all else fails, convert them to DNG.  PixInsight is happy to use DNG files.

Mark

9
General / Re: PixelMath with non-RGB channels
« on: 2019 August 22 07:30:48 »
Quote from: wadeh237
Is it possible to manipulate channels in the various CIE color spaces with PixelMath?

I can see that there are functions to read them, but I don't seen an obvious way to write them into the output image.

Take a look at the ChannelExtraction and ChannelCombination processes.  They might allow you to achieve what you want.

Mark

10
I now have a Nikon Z6.

A quick test shows that PixInsight already supports the following raw file formats:
•14 bit Lossless compressed
•14 bit Compressed
•12 bit Lossless compressed
•12 bit Compressed

Uncompressed is not supported but I can't think of a good reason to use uncompressed anyway.

Mark

11
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:

https://www.libraw.org/news/libraw-0-19-2-release

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.

Cheers,
Steve

https://www.libraw.org/ and the comments at the bottom of https://www.libraw.org/news/libraw-0-19-2-release give the impression that LibRaw version 0.19.2 does not yet support the Nikon Z7 but the later code snapshot 201903 does.

Mark

12
Quote from: niccoc1603
Quote
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 https://www.qhyccd.com/bbs/index.php?topic=6159.0
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.

Mark

13
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.

Mark

14
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.


Wouter

It appears that there could be a difference between USB2 and USB3. ZWO mentions the difference between UBS2 and USB3 here:
https://astronomy-imaging-camera.com/tutorials/what-is-amp-glow.html

Mark

15
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.

Mark

Pages: [1] 2 3 ... 15