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 ... 16
1
Thanks Mark - Is a fix planned? 


The new LibRaw behaviour is correct, I believe. 
Indeed, if you look in the "CR2 CFA Pattern" attribute in the 600D EXIF header you will see [Green, Blue][Red, Green]

Mark

2
Try GBRG.

The Canon 600D is one of the cameras affected by a recent fix in LibRaw which is the library PixInsight now uses for performing the raw conversion.  So it now requires GBRG instead of the previous RGGB.
 
A detailed explanation is here:
https://pixinsight.com/forum/index.php?topic=14219.0
 
Mark

3

While that explanation initially makes sense to me, where did you get it from? I have seen others guess that, with an OSC camera, the first 3 columns represent rgb (and they're so labelled) and that the 4th column is some kind of composite. Another explanation is that the columns represent the particular bayer pattern, in order, for that camera.  It would be nice if the developer(s) of the script would weigh in or if there were some documentation on it, but I haven't found it. If the 4 columns represent the bayer pattern, then I'm puzzled why some measurements - dark current, for example - show a variation greater than a factor of 4 in the measurements.

There's no need for guessing what the columns represent - I arrived at the explanation by looking at the script!

Also the calculation of dark current is erroneous:  https://pixinsight.com/forum/index.php?topic=11800.0
That's why you are seeing the large differences in "dark current".

Mark

4
You are seeing a range of values for gain of 1.574-1.584 and for read noise 2.669-2.736

I consider that to be pretty good agreement.

Mark

Yes, obviously, Mark.  Other values in the report vary significantly between columns, so I’d still like to know what the columns represent with a color camera.

The Bayer matrix has blocks of 2x2 pixels and in each block there is a red, blue and 2 green pixels - making 4 channels.  Each column in the report represents one of these channels.  So there is a column for the red channel, a column for the blue and 2 columns for green.  However the column order is not always clear.

Mark

5
You are seeing a range of values for gain of 1.574-1.584 and for read noise 2.669-2.736

I consider that to be pretty good agreement.

Mark

6
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

7
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

8
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

9
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

10
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

11
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

12
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


13
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

14
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

15
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

Pages: [1] 2 3 ... 16