ASI071 MONO8 and RAW8 data

rogue

Hello,
The data downloaded from my ASI071 when I ask for MONO8 or RAW8 format images contains errors. The data in both cases does not properly cover the 8-bit range 0 to 255. In the case of the MONO8 images the maximum data value is 219!???!!!!*!!

The ASI071 is said to provide 14 bit output. Does this mean that the MONO8 and RAW8 image formats do not work properly and should not be used with this camera?

The RAW16 and RGB24 format images appear to work properly and data from the RAW16 image scales down properly to 8 bits when I do it in my own software.

Thanks in advance,

rogue.

Tech@ZWO

rogue
What is the error message?

rogue In the case of the MONO8 images the maximum data value is 219!???!!!!*!!

Do you mean even the image is overexposure, the max value is only 219? Could you take images in sharpcap and choose MONO8 and RAW8, then check the histograms?

rogue The ASI071 is said to provide 14 bit output. Does this mean that the MONO8 and RAW8 image formats do not work properly and should not be used with this camera?

It will cut 6 bit and down to 8 bit if choose 8 bit images.

rogue

There is no error message. The observations are from my own histogram program using the SDK. I am only obtaining still images NOT video, The problem is with the MONO8 images. The only RAW8 problem is the unexpected zeros in the data file. I am using Linux.

Yes. When the image is totally overexposed - looking at a bright white screen with 1second exposure and gain400 -
the maximum value with MONO8 image is 219. Examination of the raw data, output as a fits file and examined with a hex file editor (Ghex), shows all values to be DB except for a group of zeros at the end of the file. Using Sharpcap on a windows PC: the histogram with the same input also shows all data points at 219.

Using a RAW8 image output the fits file shows all values as FF - except for the cluster of zeros at the end of the file again. In Sharpcap the histogram shows all pixels (R,G,B) as 255. The ASICap program in ASI Studio with RAW8 also shows all pixels R,G,B) as 255 under the same conditions.

Is the problem with the SDK software or do I have a defective camera?

Over to you,

rogue.

Tech@ZWO

rogue Got it, our devs are looking into this, will get back to you soon. thank you for your test.

rogue

Hello again,

Ignore the references to clusters of zeros at the end of the FITS files. These are just padding to ensure that the length of the file is a multiple of 2880 bytes - a FITS file format requirement. I wrote the program several years ago and had forgotten about this!!! The padding is ignored when I read the image data from the file.

rogue.

rogue

Hello again,

I have uncovered an additional problem with the RAW16 output from my camera.

Using the SDK in linux the RAW16 fits file output for an overexposed image (examined using Ghex) shows all the values to be FF7F (65407 decimal).

Using Sharpcap on a Windows PC and outputting a RAW16 fits file for the same overexposed image (examined using HxD) shows all values to be 7FFe (decimal 32766). The Sharpcap histogram, however, gives all the values as 65472 (hex FFC0).

The Sharpcap results are mutually contradictory and are different from the ones given be the SDK.

On top of this, since the ASI071 output is 14 bits i would have expected the result for a saturated image to be either FFFC if the values were written in the top 14 bits or 3FFF if they were written in the bottom 14 bits. Neither appears to be the case here!

Back to you again.

rogue.

rogue

Hello yet again,

After some thought and experiment I have solved the RAW16 problem described above - I think!

It appears that the 14bit output from the ASI071 is provided as the middle 14 bits of the RAW16 output. The highest and lowest bits do not count.

The SDK on my linux machine provides a fits file with the 16bits in computer input-and-output compatible little endian format. Sharpcap on a windows PC provides fits file RAW16 values in big endian format. The FF7F from the SDK given above and the 7FFE from Sharpcap both contain the same 14 middle bits - all set to 1. So the SDK and Sharpcap outputs are identical.

When it comes to constructing a histogram Sharpcap scales the 14 bits up to 16 (i.e. multiplies them by 4) then divides
the range into 512 intervals each of 128. It plots the numbers in each interval as a histogram and labels each interval with its middle value. That makes the label on the highest interval 511*128 + 64 = 65472. This is the value shown in the histogram.

So - problem solved. No need to look at that in addition to the previous one you are already investigating.

Good luck.

rogue.

Tech@ZWO

rogue Got it, thank you for your updates. we will fix it as soon as possible

Tech@ZWO

rogue Thank you for your patience, I discussed this with our devs, the max value in mono8 is 219 instead of 255 because it was converted from YUV format

rogue

Thank you for the information. Now please can you explain why a digital camera should need to use as a MONO8 level a luma value extracted from a colour system created 42 years ago for analogue TV (CCIR 601)?