Rendering stars in the night sky, astronomy visualization in ACES

[mkschmitty (Mike Schmitt)]

Hello ACES community,

I work at the California Academy of Sciences Visualization Studio where we make films for Morrison Planetarium. We have started using ACES for our next production. Woohoo!

Our config is derived from the one described at RedShift:
Redshift User Guides, which uses the OCIO v2 naming convention for IDTs, ODTs and Views.

I have a question about visualizing stars as small points of light in the night sky. Most astronomy visualizations we are aware of work in sRGB color space. And astronomers in planetariums can be very particular about the look of the stars

The 2D background image of the night sky we will use comes from these wonderful rendered EXR layers generated by Ernie Wright as the NASA Science Visualization Studio.

NASA Scientific Visualization Studio | Deep Star Maps 2020

These images were rendered from Hipparcos, Tycho and GAIA star data. The images are in floating point linear sRGB colorspace with a D58 whitepoint. A detailed description of how the star colors are derived can be found on their website.

Here Ernie described the look of the brightness of his stars to us:
“The bright stars are created using an exponential falloff where the maximum pixel level at the center of the stars is 3.0. When this is clamped to 1.0, the effect is to produce a white disk surrounded by a faint blue or yellow halo. This mimics what happens in photos, where bright stars oversaturate the sensor. It’s approximately the (clamped) Airy pattern or the point spread function of an optical system.”

Point spread function

Airy disk

The questions now for us is how do we closely match Ernie/NASA’s star look in ACES if we use his linear sRGB EXR images as texture maps?

First, we are confronted with the classic “sRGB texture appears too dark in ACES” issue, that I am still trying to wrap my head around, and is mentioned in many places, such as here:

ACESCG and SRGB Questions - Texture Asset Creation

Hey guys, I’m trying to learn acescg and would like to incorporate it on my color map processing in nuke. Just read this awesome thread: I have few questions: Is it correct to say that OCIO-ACESCG color space will make my “color grading, highlight and shadow recovery” more “easy and doable” because I have a bigger gamut range with acescg versus srgb. Or should I just stay in the default linear srgb (nuke-default) color space in nuke because OCIO-ACESCG just does not give a signific…

With my limited experience, the ACES 1.0 SDR-video View shows fantastic results - for example how it handles super bright values in clouds or specular reflections in water from the sun, with the elegant falloff from super brights to dark. But transforming legacy sRGB imagery with an established look, to an ACES workflow seems fraught for us newbies – most likely a result of still having our feet in both sRGB and ACES ponds without having fully transitioned to ACES.

If I take Ernie/NASA’s EXR image of the Milky Way, read in Nuke with Scene-Linear Rec.709-sRGB IDT, and view through the ACES 1.0 SDR-video (sRGB) View, it appears dark as expected. I’m able to grade the Milky Way portion of the image to get a reasonably good perceptual match (using gamma, gain and contrast) as compared to the same sRGB image viewed through the Un-tone-mapped View without color grading. Though, the brightest areas in the ACES image are dulled a bit.

Screengrab, Scene-Linear Rec.709-sRGB IDT, Un-tone-mapped View (sRGB)

Screengrab, Scene-Linear Rec.709-sRGB IDT, ACES 1.0 SDR-video View (sRGB) with color grade to match.

It’s hard to see here, but the bright stars are much harder to grade to match. As viewed through ACES 1.0 SDR-video View (sRGB), they appear dull, and lose the hot core.

To illustrate this, here’s a screengrab of an array of the bright star sprites Ernie generated, as viewed through the Un-tone-mapped View, with a scene-linear Rec.709-sRGB IDT in Nuke.

Notice the bright hot core for each star.

And the same image through the ACES 1.0 SDR-video View (RRT/ODT), the bright star cores become darkened/dulled and the stars end up appearing blurry.

It’s subtle, but this star dullness is noticeable on our planetarium dome screen when I output Ernie’s star map this way – ie. 1) read with scene-linear Rec.709-sRGB IDT, 2) try to color grade to match, 3) output with ACES 1.0 SDR-video ODT (sRGB) for viewing in the planetarium, on our sRGB projectors.

Of course, I could cheat and achieve a perceptual match to the Un-tone-mapped View, by using Invert ACES 1.0 SDR-Video as the IDTm then View through ACES 1.0 SDR-Video, but as I have read many times on ACES related pages, this is a big NO NO because the values come out super wonky. And when the image is scaled or blurred, the star colors go crazy.

Without having to bother Ernie at NASA (who doesn’t use ACES), does anyone have a suggestion how to best achieve a nice looking star with a hot core within ACES? I don’t see it just as a matter of tweaking the gamma, gain and/or contrast on the original image.

My guess is we need to basically start over – redesign the gradient falloff of each star sprite, to emphasize the hot star core, to mimic the point-spread-function while counteracting the tone-mapping component of the ACES 1.0 SDR-Video View?

And, if at all possible, we would like to try to avoid working in two separate color spaces in our 3D scenes and Nuke comps, ideally everything would live in ACES.

Has anyone else dealt with this problem?

Thank you for your assistance.

ps. Here is Ernie’s star sprite EXR which my display-referred screengrabs were generated from if you would like to play around with it.

https://drive.google.com/file/d/1vYKpHHLnA-PZBrLcYBclUsDARfj0ZNZz/view?usp=sharing

[Derek]

Un-tone-mapped clamps at 1.0. The effect of the glow on the stars is happening on this image because the core is above 1 and the glow is below one. The ACES ODT instead clamps at around 16 and remaps everything below that to a 0-1 range. So to get it to act in a similar way under the ACES ODT you’d need to separate the core part from the glow part and adjust both for the ACES tone mapping. Here’s a very imprecise attempt in that in Nuke:

set cut_paste_input [stack 0]
version 13.2 v1
Read {
 inputs 0
 file_type exr
 file "D:/foobar/star_sprites.exr"
 format "640 640 0 0 640 640 1 "
 origset true
 colorspace "scene-linear Rec.709-sRGB"
 name Read2
 selected true
 xpos -141
 ypos 88
}
set N66668400 [stack 0]
Grade {
 blackpoint 0.5
 white 1.5
 name Grade1
 selected true
 xpos -35
 ypos 218
}
push $N66668400
Grade {
 gamma 1.26
 name Grade2
 selected true
 xpos -141
 ypos 218
}
Merge2 {
 inputs 2
 operation plus
 output rgb
 name Merge1
 selected true
 xpos -141
 ypos 283
}