Hemisphere:  Southern  ·  Constellation: Scorpius (Sco)  ·  Contains:  1 b Sco  ·  2 A Sco  ·  3 Sco  ·  4 Sco  ·  6 pi. Sco  ·  Sh2-1  ·  The star 1Sco  ·  The star 2Sco  ·  The star 3Sco  ·  The star 4Sco  ·  The star πSco
Getting plate-solving status, please wait...
Sh2-1 LRGB, 


            Jim Lindelien
Powered byPixInsight

Sh2-1 LRGB

Getting plate-solving status, please wait...
Sh2-1 LRGB, 


            Jim Lindelien
Powered byPixInsight

Sh2-1 LRGB

Imaging telescopes or lenses: Celestron RASA 11

Imaging cameras: ZWO ASI128MC Pro

Mounts: iOptron CEM120EC

Software: ASCOM Platform 6  ·  Pleiades Astrophoto PixInisight 1.8 Ripley (x64)  ·  Cartes du Ciel  ·  MaxIm DL  ·  StarNet++  ·  Affinity Photo

Filters: Astrodon Tru-Balance Generation 2 E-Series - L 50mm - NIR Blocked

Accessory: QHYCCD Polemaster  ·  Baader UFC Filter Slider  ·  iOptron Tri-Pier 360

Dates:June 14, 2020

Frames:Astrodon Tru-Balance Generation 2 E-Series - L 50mm - NIR Blocked: 235x30" (1h 57' 30") (gain: 240.00) -5C bin 1x1

Integration: 1h 57' 30"

Darks: 62

Flats: 128

Bias: 196

Avg. Moon age: 23.25 days

Avg. Moon phase: 38.42%

Bortle Dark-Sky Scale: 3.00

Mean SQM: 20.75

Mean FWHM: 3.10

Temperature: 25.00

Astrometry.net job: 3676299

RA center: 15h 53' 50"

DEC center: -26° 0' 36"

Pixel scale: 2.948 arcsec/pixel

Orientation: 41.096 degrees

Field radius: 1.803 degrees

Resolution: 3840x2160

Locations: N. America, Pahrump, Nevada, United States

Data source: Backyard


Near to the popular Rho Oph region, this dim Ha emission and blue reflection nebula around Pi Scorpii gets far less attention.

Drizzle integrated at 2x for processing then cropped to 16x9 aspect and down-sampled to UHD.

I struggle with loss of color from OSC data under PixInsight although Arcsinh Stretch helps a lot. OSC sensors such as Bayer chips are designed for the demands of terrestrial daylight photography and are not ideal for astro work. Awhile ago out of curiosity I exposed conventional daytime scenes of photographic chip charts with my ZWO cameras (i.e., mono sensors with quality RGB astro filters, vs. color cameras with OSC sensors) then processed these images in PixInsight. Studying these led me to realize that while astronomical RGB filters have sharp bandpass cutoffs and little to no spectral overlap, OSC sensor filters have substantial spectral overlap, washing out color in astronomical applications due to blending between the R, G and B channels.

To get around this I use a color correction transformation matrix operation in PixelMath that has the effect of isolating each color channel and removing cross-color blending (note the coefficients and plus and minus signs; for each channel the intended color is boosted and the cross colors are scaled and subtracted). Specifically, I take the OSC's debayered stack image and break it into separate R, G and B greyscale images, then apply PixelMath as described below, and select the option to produce an RGB color output.

Let's take a look at this transform. For example the R equation in plain English states that the R channel Bayer filters pass 19% of the green signal as cross-mixing and 3% of the blue, relative to typical sharp cutoff wavelength passbands of RGB astronomical filters.

The transform relates the adjusted RGB values to the original raw values as follows:

Radj = 1.22*Rraw-0.19*Graw-.03*Braw



.... and be sure to use PixelMath's rescale option to prevent over/underflows. Also, I used a short exposure time so as not to saturate star cores.

After the raw integer data are converted to 32-bit floating point values (i.e., assuring no signal data is actually lost), I apply this correction very early in post processing since the idea is to mimic raw data from a mono sensor paired with astronomical filters.

These coefficients seems to work well for the spectra of my ZWO cameras' Sony Bayer sensors but it's easy to just experiment a little for what works best with any new camera, taking care that for each RGB equation above the coefficients add to 1.0. (Failing to do so will introduce an overall color cast.) Proceed after with the usual gradient removal, background neutralization and so on.

Some images benefit more than others, and tweaking the matrix coefficients is fair game if one's goal is for the aesthetic vs. the scientifically rigorous. Transforming this image data brought out nicely the blues and yellows of the star field, and the subtle shades of the nebulosity.

A call for more precise terminology regarding use of the term "raw file"

When the astronomical community refers to a raw file, we mean a file that contains linear un-stretched and unmodified pixel ADU values: about as raw as one can get. However, it seems rarely if ever to be the "raw" file content delivered to conventional photographers from their DSLRs. For the non-astro community, a "raw" file is un-stretched, but is generally not direct sensor data. Manufactures employ undocumented proprietary preprocessing in-camera to raw sensor data. I know that my own DSLR produces much better color "straight out of the camera" than any cooled OSC astrophotography camera I own. It is certainly noisier, being an ambient temperature sensor, but the color needs much less treatment in PI to render. What's going on inside DSLR firmware are, I assume, transform steps much like the example given herein. Both communities would avoid confusion by defining and employing a more precise terminology, it seems to me. One that distinguishes between these two kinds of "raw".


Unguided mount tracking at King rate.


Comments are closed.