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

Waxing crescent Moon, and a few processing observations

  • Please log in to reply
20 replies to this topic

#1 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 01 April 2020 - 04:46 AM

This image was captured on March 30, 2020 (03:30UT time corresponds to the next day), with my 6" Newtonian scope and ASI183mm with 610nm long pass filter.  In the post below the image, I will outline a few observations related to color space and tone curves that I find interesting.  Whether or not anyone finds it useful is another story!

 

https://flic.kr/p/2iKR8By

 

Moon-03-30-2020-TG.jpg


  • eros312, Ed D, jdj and 4 others like this

#2 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 01 April 2020 - 05:03 AM

I’m often asked about processing lunar images, particularly with regards to restoring natural shadow detail along the terminator. Here are a few interesting observations, that may or may not be useful. 

 

One source of confusion, I think, is that people are being misled by the way a raw image of the Moon taken with an astronomy camera displays on your screen, such as when you open it is Photoshop.  These images always appear very dark, with unnatural contrast.  The stacked output file from AS!3 is maintained as a linear file, and doesn’t have any embedded color profile.  Your display device has a gamma associated with it, typically 2.2.  In order for the raw images to display properly (representative of what the camera recorded), they have to be encoded with the reciprocal gamma curve in order to restore the linear image.

 

Without an embedded color profile, Photoshop will usually assign either sRGB or Adobe RGB for color images, or Gray Gamma 2.2 for grayscale images.  When you assign one of these profiles, Photoshop assumes that the image has been gamma encoded, with approximately a 2.2 gamma.  But it has not.  So what we see is the effect of the display gamma being inappropriately applied to the unadjusted linear image.  Shown below is an example. 

 

assigned-default.jpg

 

The second image below is the same as the first, and the only difference is I have created a custom color profile designating the input gamma as 1.0 (linear image), instead of 2.2.  Notice how the image is much brighter, but the histogram remains unchanged.  That’s because the histogram is still showing the linear data, but Photoshop is now applying the proper gamma to the input image so that the monitor gamma brings the image back to the original linear state.  

 

assigned-gamma1.jpg

 

The third image is again the same image, but this time after converting the color profile to sRGB after first opening it with the custom gamma=1 profile shown above.  Note that the second and third images look identical, but the histograms are completely different.  That is because the first histogram is linear, and the second has been gamma transformed, but represents the identical data.  There is a large difference between the effects of “assigning” and “converting” color profiles in Photoshop.  

 

converted-sRGB.jpg

 

So what’s the point of all this?  This information doesn’t necessarily help with processing lunar images, because you can (and should) always adjust the tone curves by eye to achieve both a good look on your monitor, and a histogram that makes sense.  However, I consider the information useful because there do appear to be misunderstandings about why the raw images look so dark.  When you take a properly exposed image with a DSLR or mirrorless camera, you never actually see the raw linear file if you simply open in a raw editor like Adobe Camera Raw, even if you “process” your raw images.  Those images have already been gamma encoded by the raw editor before you see them.  Images from the astronomy cameras have not.  Final editing decisions are always personal, but people might make different decisions if they knew that opening the raw images in the default working space in Photoshop is assigning a strong unnatural tone curve to the original image, and so you are starting from behind when it comes to shadow recovery.  It’s apparent in image 2 and 3 above that the raw image doesn’t have anything approaching black clipping, including the background sky, unlike the raw image when opened as default (image 1).


  • Herr Mario, Tyson M, Lacaille and 4 others like this

#3 james7ca

james7ca

    Cosmos

  • *****
  • Posts: 8,248
  • Joined: 21 May 2011
  • Loc: San Diego, CA

Posted 01 April 2020 - 05:10 AM

The tonal range in that image is very good. You even managed to capture some shading and detail in the bright rim of the crater Proclus which isn't that easy to do.


  • aeroman4907 likes this

#4 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 01 April 2020 - 05:17 AM

Another conclusion to the above is that the histogram in Firecapture is linear, and therefore even a 50% value represents only 1 stop away from saturation for the brightest pixels.  I've made a few statements in other threads about gamma in histograms that are incorrect, although the bottom line remains the same.  I generally advise a 75% histogram in Firecapture for the Moon, simply based upon personal experience.  I just don't see the need to go lower, because I don't have a problem with clipping.  However, if you did reduce the value to 50%, you would still have plenty of exposure.

 

Also note that if you are working in sRGB space in Photoshop (or Adobe RGB, or Gray Gamma 2.2), any adjustments you make to the tone curve operate in gamma transformed space.  For example, raising the exposure by 1EV from a level of 128 yields a value of 175, whereas if you are working in linear space this would clip to white at 255.  

 

In the above image, I exposed at a 95% histogram.  I don't normally go that high, but I was trying to get some Earthshine details in the same shot (that's another story though).  This does show, however, that even at a 95% histogram, the amount of white clipping can be controlled quite well. However, if conditions are unstable and the histogram is moving around a lot during capture, this would not be advisable.  

 

Finally, the key point that I find interesting here is that if someone were to simply open the raw image in a standard photo editor, it appears to be underexposed.  In reality, however, the image is exposed all the way to the max, as evidenced by the subsequent images that have appropriate gamma corrections to display the linear image.  


  • aeroman4907 likes this

#5 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 01 April 2020 - 05:37 AM

The tonal range in that image is very good. You even managed to capture some shading and detail in the bright rim of the crater Proclus which isn't that easy to do.

James, thanks.  I'm now thinking that the dynamic range in a "typical" lunar image is perhaps not as high as I previously thought.  Since the raw histograms are linear, it does allow for comparisons of illumination between regions fairly easily.  In my raw stack, the very brightest pixels in the rim of Proclus are reading 240-245 out of 255.  The background level near the terminator is at a 3, and the regions that start contributing significantly to details present in the final version are at about a 4-5.  If you subtract the background sky levels, there are still only 8 stops of exposure separating the darkest shadows from Proclus in this image.  I think that the difficulty of getting detail from the deepest shadows, and in the extreme case the Earthshine side in the same shot, has less to do with the dynamic range of the sensor, and more to do with the fact that the faintest details are near the same level as the background sky and the noise floor.  It's difficult to separate those details with precision.  The estimated DR of the ASI183mm at the gain I used here is about 11 stops, and it appears the actual dynamic range present in the image is less than that.


Edited by Tom Glenn, 01 April 2020 - 05:40 AM.


#6 aeroman4907

aeroman4907

    Apollo

  • -----
  • Posts: 1,214
  • Joined: 23 Nov 2017
  • Loc: Castle Rock, Colorado

Posted 01 April 2020 - 09:22 AM

Not a wasted post Tom.  We've had a number of related discussions recently related to this topic, so I won't comment too much further.

 

Regarding the histogram for this capture, it does seem that capturing at 90% to 95% histogram in crescent phases up to the quarters does appear to work well for not blowing out the highlights and being able to reasonably increase the shadows.  Well done as always!



#7 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 02 April 2020 - 02:16 AM

Thanks, Steve.  

 

Here is an interesting example showing how raw images can easily be deceiving.  I know Steve and I have discussed some of this in other conversations, but this may be of interest to others.  Many of us also take images with DSLRs or mirrorless cameras.  Even if you edit your raw files, rather than use the JPEGs, the raw file is rendered by a program such as Adobe Camera Raw.  During the rendering process, and before you even see the image, the gamma is adjusted, and also a significant additional tone curve is applied to the image.  These adjustments are specified in the raw file itself (NEF files in the case of my Nikon).  This occurs before you even see the file to begin editing in Photoshop.

 

If you want to see what the raw linear file from a DSLR (like my Nikon) looks like if you take it and directly assign it to sRGB color space without any gamma or curves modifications, you need to use a different image editor that allows you to pull the linear files after debayering, but before gamma and curves adjustments.  I used RawTherapee for this.  Shown below are two examples from tonight with my Nikon D5600 and 6" Newtonian.  In the first example, I set the exposure manually to what I would consider a good base exposure for the DSLR.  This is based upon taking an image and then viewing the preview on the back of the camera, and checking to see that the histogram is close to the right edge but not quite touching (1/250s in this case).  Most people know that the raw images are more forgiving than the JPEG previews with regards to overexposure, but the true raw image (not the rendered raw image) is somewhat surprising.  You can see below that the JPEG produced in camera looks pretty decent, with midtones lying mostly in the middle of the histogram, and nothing is clipped.  However, the linear file, if inappropriately assigned to sRGB space without any gamma or curves adjustments, is barely perceptible.  The image histogram (still linear) has the brightest pixels at 29%, or nearly two stops below saturation.  Note that this is not how this image appears if you open in Adobe Camera Raw.

 

So, this is the same exposure as if you took a video in Firecapture at a 29% histogram.  The difference is that in this case, you never see the unadjusted linear image unless you look for it, but instead see a highly processed version by Nikon.  This is true even if you edit raw files.  

 

Nikon-comparison1.jpg

 

I took another image at two stops higher exposure, in this case 1/60s.  Shown below is the JPEG from the camera, as well as the linear raw file directly assigned to sRGB without any gamma or curves.  In this case, the histogram fill of the brightest pixels is 82%.  This makes it approximately the same exposure to most of my lunar images I take with my ASI183mm using Firecapture.  These images will look underexposed if assigned to sRGB color profile and opened in Photoshop, and that is also the case with this Nikon image.  You can see from the JPEG produced in camera that the image is anything but underexposed, and is in fact an extreme "expose to the right".  Although the JPEG is shown here, the rendered "raw" file opened in Adobe Camera Raw looks basically identical.  Ignore the blurriness of the image.  It's the only example I had from 1/60s, and the image isn't very sharp, but the only relevant thing here is the tonal curve.  

 

Nikon-comparison2.jpg

 

Anyways, just food for thought on how to interpret exposures, histograms, and the perception (sometimes incorrect) of what constitutes a "good" exposure.  It's fair to say that anything above 75% in a linear histogram corresponds to a very good level of exposure, such that the raw image, if tonally adjusted for gamma, will appear overly bright and washed out.  But as long as no clipping occurred, this is easy to correct, and does allow for higher shadow recovery, especially when stacking many frames.  However, if you directly assign the image to sRGB or similar color profiles, you may mistakenly think the image is underexposed, and the shadows are crushed down very low.  They are, however, very recoverable.  The example from my Nikon shows that most of this heavy lifting is done by the combination of the camera and the raw editor, which we don't have the benefit of when processing images from astronomy cameras.  I am only addressing grayscale issues in this post, but these difficulties also extend to color, because it turns out the raw files from Nikon (and other cameras) have very excellent color correction profiles associated with them that are also implemented by the raw editor before you even see the file.  This led Andrew on his quest to try and calibrate his ASI224.  


Edited by Tom Glenn, 02 April 2020 - 02:18 AM.

  • Herr Mario and Tulloch like this

#8 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 02 April 2020 - 03:44 AM

You may notice that my exposures in the examples above of 1/250s and 1/60s differ by 2EV, but the difference between a linear histogram of 29% and 82% is only 1.5EV.  This difference is accounted for by a layer of thin clouds that was intermittently present during this test.

 

Also noteworthy is that the 1/60s exposure is when the "blinkies" started appearing in the preview screen of the Nikon.  These are overexposure warnings.  In general these can be risky to trust, because they are based upon the jpeg preview.  Although in this case they worked pretty well.  This example shows that despite some clipping in the jpeg, the raw file didn't have any clipping.  However, if no adjustments are made, this exposure will appear overexposed.  I would not use this exposure if I was just trying to take a quick photograph of the Moon with my DSLR, as there is no need.  The photograph that resulted from a 29% exposure was very good.  These higher exposures are very useful for stacked data from the astronomy camera however (since these have to be processed anyway), and play an important role in shadow recovery, provided that no pixel saturation occurs.  


Edited by Tom Glenn, 02 April 2020 - 03:45 AM.


#9 DMach

DMach

    Apollo

  • -----
  • Posts: 1,133
  • Joined: 21 Nov 2017
  • Loc: The most light-polluted country in the world :(

Posted 02 April 2020 - 07:57 AM

Very useful info Tom, thanks for taking the time to post it all!

#10 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 03 April 2020 - 02:33 PM

Thanks Darren.

 

Here is an additional comparison panel that I find interesting, because it highlights how "raw" files that you see from a DSLR can be very deceiving, depending on just how raw they are.  The legend explaining panels 1-4 is below the image, but noteworthy is that if you load a "raw" file from a camera such as a Nikon or Canon into a raw processor such as Adobe Camera Raw (ACR), you start at the image shown in panel 3, whereas the raw file from an astronomy camera looks like panel 1, if you assign to sRGB.  All panels below were generated using RawTherapee, and they are the processing steps performed automatically using the embedded profile information in the Nikon NEF file.  Much can be gleaned about "normal" image processing by following what a consumer camera does to recreate what most people would perceive as a natural view.  

 

Nikon-in-camera-processing-TG.jpg

 

Panel 1- The raw linear file, assigned directly to sRGB without any gamma or curves adjustments (you would never do this normally).

Panel 2- The raw file transformed with gamma into Adobe RGB color space (gamma 2.2, which is the inverse of your display gamma-sRGB would be nearly identical).

Panel 3- An additional tone curve, specified automatically from the Nikon profile.  This is the version that comes out of the default ACR (Adobe Camera Raw) processor.

Panel 4- The JPEG produced "in camera".  Note the additional tone curve to give the image some "pop".  Again this is specified according to the auto Nikon profile.  


Edited by Tom Glenn, 03 April 2020 - 02:35 PM.


#11 Tulloch

Tulloch

    Apollo

  • *****
  • Posts: 1,160
  • Joined: 02 Mar 2019
  • Loc: Melbourne, Australia

Posted 03 April 2020 - 04:53 PM

Fascinating stuff Tom, I feel as though you are on the verge of something which may change the way lunar (and perhaps planetary) imaging is processed moving forward. Kudos also on learning how to use RawTherapee and its bewildering array of settings and controls.

 

There seems to be indications that there is a lot more useful data in the lower part of the histogram than may have been previously thought for these stacked 16-bit files. I assume that this technique is more appropriate for astronomical cameras using 12 bit captures and low gain values (for which the moon is an ideal target)? Could this method be extended to planetary imaging using 8 bit captures and high gain, or alternatively capturing in 12 bit and using low gain values, where the histogram is lower than what would be considered "normal"? Or is the noise floor too high in these situations which no amount of stacking could recover from.

 

I'm thinking specifically of whether it is possible to extract additional data from low intensity targets like the dim moons of the planets rather than anything specific from the planetary discs themselves . Since the planets don't really have shadows (other than behind the rings of Saturn or transiting moons), I don't think there's much to be gained from the discs themselves, but extracting details of these moons could be interesting.

 

I am interested to see how far you can go with this, and what implications it might have for the rest of us. Keep up the good work smile.gif .

 

Andrew



#12 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 04 April 2020 - 03:27 AM

Andrew, thanks for the kind words and comments.  You may be one of the few that reads through these ramblings in detail.  Your post about color, and some of the responses contained therein, was partly the instigator for this analysis.  I don't think I'm revolutionizing anything here.  Rather, I think it's a revelation on how much spare time I've had during the COVID-19 lockdown.  I've been editing raw lunar images that were assigned to sRGB and Adobe RGB for several years, and there has been no negative impact on the final outcome.  What puzzled me all along, however, was that it always seems as though I had to make extreme adjustments just to recreate a natural view of the Moon.  In hindsight, it's perfectly obvious: The images had no gamma applied to them in the color profile and so they were not displayed properly on the gamma 2.2 monitor.  This explains the strong tonal curves required.  The first curve simply had to undo the effects of the display gamma, and then on top of that any additional adjustments according to taste.  

 

As for whether this could apply to planetary imaging, regarding detecting faint moons, all of the data should still be there no matter what color space you are working in, unless you have done something weird in Photoshop.  So I'm not sure of any improvements there.  This mostly has to do with my desire to better understand what is happening to the raw data from the moment it leaves the sensor to when you view it on screen.  For images that are designed to be viewed in sRGB (such as JPEGs produced by every camera), the color profile embeds gamma data into the file, such that when your monitor displays it with a gamma of 2.2, it looks normal.  This is a carryover from CRT days.  A CRT has a natural built-in gamma of about 2.2 because of the non-linear relationship between the input and output of the electron gun that excites the phosphors in the screen.  If the input signal wasn't gamma encoded, it would look very dark, and very different from the version the camera recorded.  So the gamma encoding and decoding process neutralize each other.  LCD screens are inherently linear, and don't require gamma, but for compatibility reasons this has carried over.  Also, modifying the input versus the output gamma has some other benefits related to maximizing the display potential of 8 bit monitors, but that's a separate topic.  But when you open a linear image with no color profile (and no gamma) in sRGB space, your monitor is expecting that the data is gamma encoded, and it still has it's output gamma, and so the image displays dark.  This is equivalent to taking a normal image (JPEG) and opening in Photoshop, and then creating a Layers adjustment and setting the gamma to 0.45, which is 1/2.2.  This recreates the effect that we see.  

 

So this clears up the reason why raw images from astronomy cameras display abnormally dark when opened in Photoshop (this is especially obvious in lunar images, because of the dynamic range).  In reality, they are not dark at all....they are simply being altered by the display.  This has implications for histogram settings during imaging.  The most obvious is that if you are trying to prevent pixel saturation in the raw image (which we are), then even a 50% histogram is only 1 stop under saturation, because the provided histogram is linear.  So a 50% histogram is actually not low, and if you applied the correct gamma to compensate for your monitor, then the raw image would not be dark.  In fact, it would likely appear washed out.  Even a 25% histogram is only 2 stops below saturation.  That said, for lunar imaging I still stand by my 75% histogram recommendation, but even a 50% recording would generate a very fine result.  And you are correct, there is a huge amount of information buried at the bottom of a linear histogram.  You just have to know how to retrieve it.  A neutral gray card has 18% reflectance, which is a 46/255 reading in a linear histogram.  So that means that anything below middle gray is recorded as below a value of 18% in your raw histogram.  That's a ton of data at the very bottom. 

 

As for your question about planetary captures in 8 bits and higher gain, everything still applies.  I have looked at a few of my 8-bit lunar captures, and I was able to pull Earthshine detail from a "normal" exposure, so even 8 bits isn't prohibitive here, although there was slightly more noise.  When stacking frames, the available detail is limited by SNR, or your ability to differentiate true details above the noise floor.  When seeing is variable, stacked 8 bit files have equivalent bit depth to stacked 12 bit files.  Usually, the background sky is above 0 anyway in the raw image, and so what you are really doing is measuring the SNR above the noise floor, rather than the dynamic range of the sensor itself.  

 

Another goal I had was to gain insight into the processing that is done within a consumer camera, such as my Nikon, and a raw editor such as Adobe Camera Raw (ACR).  I was interested to learn that on top of the 2.2 gamma transformation, there is an additional tone curve applied to the raw image by ACR (before you even see the image in the editor).  That tone curve is below, and you can download a file corresponding to it from the RawTherapee user guide.  

 

RawTherapee-curve.jpg

 

The linear 1:1 slope is hard to see in the image, but you can appreciate that this tone curve broadly increases the brightness of the image, especially in midtones and highlights, and it dips below the 1:1 line in the deepest shadows, which adds some contrast.  I found this interesting, because I had empirically found that when editing a raw lunar image in sRGB space in Photoshop, the following curve is required to restore a nearly natural view. 

 

Photoshop-curve.jpg

 

My curve is much more aggressive, especially in the shadows, but this now makes perfect sense because it is effectively including both the initial gamma transformation, as well as an additional tone curve normally supplied by the Nikon profile settings.  After using RawTherapee to get a glimpse under the hood of how ACR processes a raw photograph, I wondered if I could create a profile to do the same to lunar images taken with my ASI183mm.  Indeed, you can, but the result is not appreciably different from the strong tone curve in Photoshop.  If you attempt to use the ACR default tone curve with a 2.2 gamma in RawTherapee, you will find this to be too much, because those setting were defined to work with "normal" exposures from the Nikon, whereas the raw images taken with my ASI183mm more approximate a strong "expose to the right" technique.  Therefore, I had to reduce the strength of the gamma in RawTherapee to 1.3, while keeping the same default ACR tone curve.  You can see the results below.  The image on the left is the raw linear file assigned to sRGB.  The image in the middle was processed with nothing other than the tone curve shown above in Photoshop.  And the image on the right was processed using RawTherapee using a combination of 1.3 gamma with the ACR default tone curve, and a slight change in the black levels.  This can all be saved as a profile setting, and applied to other images, where it works pretty well as a default processing step (but so too does the Photoshop version).  The Photoshop version has slightly brighter highlights, and the RawTherapee version has slightly better shadows.  These could be equalized very easily though in Photoshop.  

 

moon-series-TG.jpg

 

The main thing that I like about these specifically defined processing schemes is that they pass the sniff test for image manipulation.  In scientific journals, you cannot manually (and subjectively) edit an image for publication.  Any processing steps are limited to steps that are applied evenly across the entire image, and can be defined by simple mathematical formulas or protocols that can be easily reproduced by anyone who downloads your source code or profile setting.  In general, no layer masks or manual selections are allowed.  This is very different from some of the techniques you see on this forum, although those are perfectly acceptable for photographic art.  


  • Tyson M likes this

#13 Tulloch

Tulloch

    Apollo

  • *****
  • Posts: 1,160
  • Joined: 02 Mar 2019
  • Loc: Melbourne, Australia

Posted 04 April 2020 - 07:54 AM

Thanks Tom, I'm sure there's a lot of people watching on here to see (like me) where this might go. I don't have anywhere near your experience in this area, only having started astrophotography last year, so I'm still learning a lot from your posts here.

 

I guess I was wondering if the gamma correction applied in Photoshop was causing a change to the levels such that it was not possible to extract the dimmer parts of the image. If all the data is still there and PS is able to manipulate the 16 bit file correctly (even if it displays it incorrectly) then that's all that matters.



#14 Tulloch

Tulloch

    Apollo

  • *****
  • Posts: 1,160
  • Joined: 02 Mar 2019
  • Loc: Melbourne, Australia

Posted 04 April 2020 - 04:48 PM

I also note that AstraImage gives you the option of not applying the 2.2 gamma when opening raw images, haven't worked out how to trick it into thinking the linear image files should be treated as raw yet. 

 

It's also the only software I've found that can show the pixel values in 16 bit (ie 0-65535 per colour) format.



#15 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 04 April 2020 - 05:16 PM

Andrew, you are correct about AstraImage showing 16 bit values, which I also like sometimes.  You can get Photoshop to show this also in the info sidebar window, But strangely, if you select 16 bit it only shows 15 bits (0-32768).  

 

I have looked at a few of my planetary captures, and discovered a couple of things that may interest you.  The first is a bit of good news.  Even assigning in sRGB doesn't lose any data, it just affects the degree to which it needs to be stretched if you want to detect faint moons.  

 

Also, I was initially puzzled that all of my histograms looked identical, with the brightest values registering at 191/255.  And then the answer became clear.  Like many of us, I check the box in AS!3 that says "normalize stack", and I have this set to 75%.  I never really paid much attention to what this means, but it's very clear now that it takes the brightest pixel value in your stack, and adjusts it to be exactly 75% on the linear histogram, which is 191/255.  Assuming you capture at below at 75% histogram, this multiples every pixel by the same value to raise the brightest ones to exactly 191.  This is before sharpening of course, which will increase the values slightly.  This raises an interesting question: If we are going to raise the histogram to 75% in post processing with AS!3, why not just raise the gain to achieve a 75% histogram during the capture?  In fact, I can't think of any reason not to do this.  When you increase the exposure in post processing, you raise both signal and noise by the same value, so SNR remains unchanged.  This is similar to increasing the gain during capture, except that on most cameras, when you raise the gain the read noise goes down.  Now, the difference here would be small, because the read noise has already started to plateau on most cameras at these gains, but it is certainly the case that raising the histogram to 75% in AS!3 will not be better than just raising the gain to achieve 75% in the raw data.  Food for thought.  



#16 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 04 April 2020 - 05:58 PM

And in terms of stretching levels and finding some surprises, here's one from June 9, 2018, at 09:51UT.  This was taken with the ASI183mm, so it's grayscale.  My Firecapture log file says my histogram was 49%.  Yet the raw tif from AS!3 has the brightest pixels at 191, exactly 75%, as you would expect from the normalization.  The difference between a 49% and 75% linear histogram is only 0.61EV, so not much at all.  So in principle, I could have bumped the gain up just a touch to achieve a 75% histogram in capture, and the result would have been identical to the operation performed in AS!3 to normalize, although I would have added the benefit of slightly reduced read noise.  Although looking at ZWO's chart, it only would have reduced read noise by maybe 0.25e-.  But still, I wonder, why not just select your shutter speed based upon desired frame rate, and then adjust gain to 75%, if we are going to normalize at 75% anyway?

 

Also, I've never really done much stretching of my Saturn images, and I'm surprised at how many times Mimas shows up (verified with WinJUPOS, of course).  Here is one example.  Shown below is the sharpened stack, opened as sRGB without any adjustments in Photoshop.  The brightest pixels went up from 191 to 203 after sharpening.  No sign of any moons yet.

 

Saturn-06-09-2018-0951UT-linear-sRGB.jpg

 

The next version below opens the file setting input gamma to 1.0.  So this is displayed as a linear output.  You can already start to see Dione, Enceladus, and Mimas, although they are faint.  

 

Saturn-06-09-2018-0951UT-linear-gamma1.jpg

 

Finally, this version takes the above and adds even more gamma adjustments.  You can now clearly see the moons.  I had a number of files from 2018 in which Mimas was clearly visible.....due to the good fortune of consistently catching it near maximum separation from the rings (purely by chance).  

 

Saturn-06-09-2018-0951UT-linear-gamma1-stretched.jpg



#17 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 04 April 2020 - 06:20 PM

And here is the raw stack of the above, unsharpened, but with the gamma stretch.  If you want to appreciate the brightness variation between the moons, you have to go back to the unsharpened data, as sharpening increases the values of the moons.  Notable below is that Mimas is barely rising above the levels of the background noise.  Using the spot checker in Photoshop, the brightest pixels in Mimas are registering at about 245/32768, and the adjacent sky is at 215/32768, for a difference of 30 (in the unstretched image, not the version below).  If we convert to 12 bits, that is only 3.75 ADU at the sensor during the original capture (although this was 8 bit mode-I assume the downsamples occurs in the computer during capture) which according to the ZWO chart, at the gain setting I used this corresponds to just under 1 electron difference between the two.  So, these cameras have very little trouble detecting signals near the noise floor, even in 8 bit captures.  

 

Saturn-06-09-2018-0951UT-raw-stack-stretched.jpg



#18 Tulloch

Tulloch

    Apollo

  • *****
  • Posts: 1,160
  • Joined: 02 Mar 2019
  • Loc: Melbourne, Australia

Posted 04 April 2020 - 06:53 PM

Thanks Tom, yes I had thought about the normalization step in AS!3 for planetary and wanted to so a bit of work to see if it was a linear multiplication of the pixel values or a non-linear stretch before mentioning it. Looks like you are one step ahead of me as usual :). Since you don't get this option in surface stacking (which I assume you use for the moon), I hadn't brought it up before.

 

My version of PS doesn't allow viewing the pixel values in anything other than 8 bit, and while it will allow some processing of 16 bit images, other steps are not available (such as layering 16 bit images, so I need to do all my processing before I add new layers, such as for the moons).

 

Interesting with the moons on Saturn (congrats on getting Mimas btw, I've not been able to capture it yet), although I wonder whether playing with the levels feature in PS would have the same effect, it would just need to be moved to a different point on the scale (see here for my recent attempt).

 

Being only a relative newcomer to all this, I don't know why people image at the max histogram level of around 50% - I just followed the advice from others here and it seemed to work well for me. Back in the days when I was using my Canon 700D to image the planets, I did try changing the settings to give a range of histogram levels, and found that imaging with them too high (above 75% or so) was detrimental to the final image quality. That was for the DSLR or course, I never really played with the ASI224MC much. For the ice giants, because they are so dim I tend to image with a level of around 30% or so, to get any larger I need to ramp the gain up really high or increase exposure time to be too long. Fortunately there's not much detail to be had on either of these planets.



#19 Tulloch

Tulloch

    Apollo

  • *****
  • Posts: 1,160
  • Joined: 02 Mar 2019
  • Loc: Melbourne, Australia

Posted 04 April 2020 - 07:05 PM

P.S. A quick question if I may - how do you open the images into RawTherapee using a gamma = 1.0? There are so many controls, I can't work it out.

 

Thanks, Andrew



#20 Tom Glenn

Tom Glenn

    Vanguard

  • -----
  • topic starter
  • Posts: 2,443
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 04 April 2020 - 07:42 PM

P.S. A quick question if I may - how do you open the images into RawTherapee using a gamma = 1.0? There are so many controls, I can't work it out.

 

Thanks, Andrew

I'm no pro at the program yet, but here's a screen shot that may be useful to you.  I added three white arrows.  The one in the lower left identifies the ICC profile creator.  Click on this and the window in the center opens, and you can choose a bunch of tone curves, including linear gamma=1.  Save your file somewhere you can find it.  The white arrow n the upper right is the color tab.  Click on that and scoll down to color management.  Click on custom and then load your file that you just saved.  The white arrow in the lower right identifies the working profile and the output profile.  I read that we should always keep the working profile as ProPhoto as default unless you really know what you are doing and have a reason.  The output profile I put as sRGB so that the converted file will be ready to go for editing in Photoshop.  But you could choose a different profile.  Also notice that you can select the option in the output profile to adjust the tone curve additionally.  It's set to "none" by default but if you select "custom" you can play around with the gamma and slope for the transformation into the output color space.  If you move the sliders you get to see what is happening in the preview window.  It can be a lot of fun, but also somewhat confusing.  

 

RawTherapee-screenshot.jpg


  • Tulloch likes this

#21 Tulloch

Tulloch

    Apollo

  • *****
  • Posts: 1,160
  • Joined: 02 Mar 2019
  • Loc: Melbourne, Australia

Posted 04 April 2020 - 08:59 PM

Yep, got it, thanks. I was able to get to the colour management tab and have a play around, but missed the first key step of creating my own colour profile art the start.




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