What, exactly, are the pixel readouts?

[GaryP]

A panel at the bottom of the PixInsight workspace shows values for R, G, and B pixels that change as one moves the cursor over the image. I wonder what it is that these values represent. My T1i has a 14 bit analog to digital signal conversion. Does a reading of say, R: 0.0150 tell me that the red channel is 1.5 percent saturated? Can I infer anything regarding the number of electrons or photons that produced that reading?

<-- Like it says on the panel, a newbie.

[bitli]

PixInsight likes to work with normalized values (0 is dark, 1 is white or fully saturated color). This is in general convenient as it is independent of the physical measurement units of your camera.

There is a right arrow at the right of the readout value, if you click on it you will see a menu where you can change the display mode. You can choose a Normalized Real Range (0 to 1) with a given precision or an integer range matching your camera (or whatever range you want). This is sometime useful to compare with other program or better understand the measured values.

The display mode is completely independent of the internal representation of images.  PI can display normalized values even if the file is stored in 16 bits, or round to any precision you want. This does not impact the calculation or stored images. In general, except for the raw images, we work with floating point 32 bit images which are better understood in term of normalized range. This is indicated by the 'f32' somewhat to the right of the right arrow (unless you changed your default display).

-- bitli


-- bitli

[GaryP]

That helps. The T1i produces raw files, so that is what I have been working with. Is there an advantage in converting them to something else? I noticed one of Harry's videos suggested converting them to 32 bit. I see many people using  the tiff format.

I don't recall ever changing the default display, but I don't see the 'f32'. See attached screen clip of part of bottom panel. There appeared to be no other information on the panel to the right of this.

[bitli]

You do not see the 'f32' because your images are still in 'i8' format (that is only 256 levels, largely not enough for your 14 bits converter !).
You should first find a way to get images in a 16 bits format from you acquisition software (even if only 14 bits are used, the 8 bits and 16 bits are the only formats really used and supported, so pick the larger one). What exact format is supported depends on your acquisition software. If it supports FITS, fine.  Otherwise TIFF is fine, but there are also 8 bits and 16 bits versions of TIFF. Be sure to get a 16 bits version directly from your acquisition software! Loading 8 bits and then converting to 16 bits is no good.

As soon as you do calculation in PI, you should use F32. Many process will create results directly in F32 (or another selectable format). When you save a file you should ensure that you save 32 bits FITS format. You can also directly convert an image using the process SampleFormatConversion, or the command 'f32' in the console.

At the beginning you may find it easier to use the BatchFormatConversion to convert all you input images to FITS 32 bits, so you have no risk to work with 8 bits or integer images.

Only at the very end you will save a copy of the final image in JPeg (8bits) or TIFF (8 or 16 bits) format.

I hope this is clearer.
-- bitli

PS. By the way we use 32 bits floating point because the mathematical operations need it, we know that human eyes cannot really distinguish 2^24 levels...

[Phil Leigh]

That helps. The T1i produces raw files, so that is what I have been working with. Is there an advantage in converting them to something else? I noticed one of Harry's videos suggested converting them to 32 bit. I see many people using  the tiff format.

I don't recall ever changing the default display, but I don't see the 'f32'. See attached screen clip of part of bottom panel. There appeared to be no other information on the panel to the right of this.

Gary,
what software (if any) are you using to control the camera? Do you capture images on a memory card or direct to the computer?

You are shooting RAW, so the Canon .CR2 files can be opened directly in PixInsight. There is no need and no advantage to changing them to another format first (except in one specific case, which is when you are creating a superbias but that is a different conversation)

[GaryP]

This is all a bit of a revelation to me and very helpful. I'll start with Phil and then answer bitli.

I am capturing with Canon EOS direct to the computer. I have been working with files previously preprocessed and stacked in Nebulosity. I have yet to register, stack, or combine any files in PixInsight. I opened the .CR2 files in Nebulosity, which saves them as .fits.

I was working under the impression that the .CR2 files and the .fit files produced in Nebulosity were 16 bits. Was I wrong about that? Or does PixInsight convert .fit files to 8 bits by default? Do I have to somehow instruct EOS to produce 14 or 16 bit .CR2 files?

I know that PI asks for bit specs when it saves a file, so if I have 14 or 16 bits coming in, there will be no problem. How can I find out whether a file is 8 bits or 14/16 bits? When I opened one of my stacks (.FITS) in Nebulosity and use Pixel Stats, it says the maximum is 65535, so that should be 16 bits. In PixInsight, I tried the script Utilities --> FITS Keywords on the stack and found the table with a check box that said BITPIX -32. Does that mean the file is 32 bits? When I save such a file in PI, the default radio button in the dialog is 16 bit unsigned integer. I have not changed that.  How or where did it get converted to 8 bits?

[bitli]

I do not know Nebulosity, so I do not know what it produces.  The absolute value of BitPix should be the number of bit per pixel (it could be float or integer), so it is bizarre that you get I8. However reading FITS data of other programs proved somewhat unreliable (the standard leave some flexibility and not all programs interpret it the same way).

May be you could check that you get I8 in a file that you load and post the original FITS one (via Endor, DropBox or GoogleDrive) so somebody could examine it?

-- bitli

[GaryP]

I think the problem is solved now. I didn't notice the little "i8" in the panel that told you it was an 8 bit file. I opened a few of the .fits stack files from Nebulosity and found that they are all "i16". I opened .fit files that I had modified in PixInsight and they were all "i16". I opened a .bmp file and found it was "i8", so I must have had a .bmp file open at the time that I made the screen clip of the panel. The good news is that I was doing all modifications on 16 bit fit files and only saving a copy of the final result as .bmp. I'll save the .fits files as 32 bit .fit files from now on and use 8 or 16 bit .tiff for distribution or presentation.

[pfile]

ok - so your CR2 files should be i16 when you open them. if you integrate some files or calibrate them with an f32 master, the calibrated or integrated image should be f32.

note that the A/D converters in newer canon cameras are 14-bits and the values are brought into the 16-bit space without any scaling. so a completely overexposed CR2 file will have values of 0.25 everywhere, because the biggest number representable with 14 bits is 16384 (really 0..16383) and the biggest number representable in 16 bits is 65536 (really 0..65535). 16384/65536 = 0.25.

rob

[GaryP]

Got it. Thanks. I'll keep the bits in mind when I try calibrations. I'm guessing the basic idea is that any files that are to be combined should have the same bit width and 32 bits is preferable.