Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Histogram Combing on Subs

  • Please log in to reply
8 replies to this topic

#1 chrisjackson184

chrisjackson184

    Lift Off

  • -----
  • topic starter
  • Posts: 6
  • Joined: 05 May 2021

Posted 12 May 2021 - 01:15 AM

Had no luck on the Beginning Astrophotography Forum, hoping someone on the advanced might be able to help!

 

I'm imaging with an Explore Scientific 16MP Colour Deep Sky (basically a rebadged QHY163C).

The two histograms below are consecutive subs (each 300s). What I am trying to understand is why one is showing combing and one not. I'm finding this occurs randomly throughout the nights imaging on the subs. If it matters I am looking at the subs in the ASIFitsView software.

Is this even a problem?

All thoughts gratefully received!

 

post-368791-0-23513500-1620246507.png

 

post-368791-0-86476800-1620246502.png



#2 jdupton

jdupton

    Gemini

  • *****
  • Posts: 3,366
  • Joined: 21 Nov 2010
  • Loc: Central Texas, USA

Posted 12 May 2021 - 09:16 AM

Chris,

 

   I am not sure of what you consider "combing" of the histogram. Can you explain?

 

   I would call combing the discrete nature of the pixel values best seen at higher values (right side) in your screen shots. With that definition, both of the histograms are showing what I would call combing. I see nothing I would say is different between the histograms for the two subs.

 

   The discrete nature comes from mapping the 12 bit sensor data to the 16 bit output FITs frame. The data the electronics reads from the sensor has 12 bits of resolution (which is a maximum value of 4095 ADU). In order to output a 16 bit FITs frame (with a maximum brightness of 65535 ADU), the device driver for the hardware multiplies the sensor data by 16x (actually shifts the binary data bits to the right by 4 bits since 12 bit and 16 bit data differs by 4 bits). This means that the output data will always be a multiple of 16. The pixels in the output file can show a brightness of 31,984 ADU (if the sensor read out 1999 ADU) but the output file cannot contain any pixel with a value between 31,985 and 31,999 ADU because those are not multiples of 16.

 

 

John



#3 chrisjackson184

chrisjackson184

    Lift Off

  • -----
  • topic starter
  • Posts: 6
  • Joined: 05 May 2021

Posted 15 May 2021 - 11:16 AM

Hi,

 

What I was referring to was that in the first histograms the data has lots of zero values in the data, and the line is jumping up and down, on ht image this makes it almost look like the curve is shaded in, but it is a line going up to a data value then back down to zero. In the second one the data points fluctuate around the curve, but always have positive values.

 

I'm trying to work out why this is happening and if it means I should be bining either of the subs.

 

C



#4 WadeH237

WadeH237

    Fly Me to the Moon

  • *****
  • Posts: 7,184
  • Joined: 24 Feb 2007
  • Loc: Ellensburg, WA

Posted 15 May 2021 - 12:10 PM

You have a 12 bit ADU on your camera.  The driver upscales it to 16 bits by shifting the values 4 bits to the left (basically, multiplying each pixel value by 16).

 

Because of this, each pixel value in a raw sub must be divisible by 16. This means that there will be zero instances of any values that are not divisible by 16.  Depending on how the histogram is rendered, this may result in visible gaps.  This is probably what you are describing.  Once you integrate a sufficient number of subs, the final result won't do this, since the averaging during integration will produce values that are not necessarily divisible by 16.

 

Edit:  This is also why a saturated pixel on a 12 bit camera is usually shown as 65520, instead of 65535.


Edited by WadeH237, 15 May 2021 - 12:13 PM.


#5 Jim Thommes

Jim Thommes

    Fly Me to the Moon

  • *****
  • Posts: 6,181
  • Joined: 20 Sep 2004
  • Loc: San DiegoCA USA

Posted 15 May 2021 - 07:36 PM

I agree with WadeH237 (mostly). Some call this effect "stride". With a 12 bit camera, stride is 16 as WadeH237 mentions. For a 14 bit camera, stride is 4 (on 16 bit fits format). If you expand the histogram of your 12 bit sub frame, you will see pixel quantities only at values of 16*n-1 where "n" is an integer (or roughly only near values divisible by 16).

 

The reason this goes away at integration is that at any pixel location in the image, integration will average the various 16*n-1 values.  So for example, if a given pixel location for 20 sub frames has 7 subs at value 15 (16*1-1) and 13 subs at a value of 31 (16*2-1), the integrated value of that pixel would be 25.4 [(7*15+13*31)/20]. The resulting value is 25.4 for a floating point integration and probably 25 for an integer integration. Let the thought experiment expand over all the combinations of 15, 31, 47... for a given pixel location, all of the pixels in an image, and you can see how the "stride" issue does not significantly effect the integrated result given enough subs (and floating point integration helps further).

 

Incidentally, just by calibrating a sub frame with flats and darks (which themselves are integrated), "stride" will also be removed/reduced.


Edited by Jim Thommes, 15 May 2021 - 07:39 PM.


#6 WadeH237

WadeH237

    Fly Me to the Moon

  • *****
  • Posts: 7,184
  • Joined: 24 Feb 2007
  • Loc: Ellensburg, WA

Posted 15 May 2021 - 11:50 PM

16*n-1

Thanks for the clarification on the "-1" part.  Of course, you are correct.



#7 chrisjackson184

chrisjackson184

    Lift Off

  • -----
  • topic starter
  • Posts: 6
  • Joined: 05 May 2021

Posted 16 May 2021 - 02:20 PM

Thanks for your input, it's starting to make sense. So it's not an issue worry about, just a function of 16bit images from a 12bit sensor. 

 

Background is I'm trying to work out why on a stacked image of the Cigar nebula ( > 100 subs @ 300s) I'm not picking up any of the red H-Alpha, sounds like need to keep digging for a reason. Still getting used to the CMOS techniques having moved from DSLR recently.

 

My imaging / stacking PC recently had a failed HD, once I've got it back up and running I'll look at the subs again and see if I can spot any issues.

 

Thanks all for now!

 

C



#8 WadeH237

WadeH237

    Fly Me to the Moon

  • *****
  • Posts: 7,184
  • Joined: 24 Feb 2007
  • Loc: Ellensburg, WA

Posted 17 May 2021 - 07:57 AM

If by "Cigar Nebula", you mean M82, the red jets you see in deep images are very faint.  You will need lots of integration time to get it and it probably won't show up unless you specifically process to bring it out.  Using an Ha filter just to catch it helps quite a lot.



#9 chrisjackson184

chrisjackson184

    Lift Off

  • -----
  • topic starter
  • Posts: 6
  • Joined: 05 May 2021

Posted 17 May 2021 - 03:22 PM

Thanks for the tip! Have been thinking about introducing an Ha filter, maybe the next purchase I need to think about.




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics