DP0.2 HIPS Images looks too shallow

[JuliaGschwend]

Hi,
recently I downloaded a couple of deepCoadd_calexp images in FITS format to the Brazilian IDAC to test our local image visualization tool under development. Cristiano Singulani ran a pipeline to make a HIPS image from the combination of g, r, i bands and the result was a bit weird. It looks too shallow to be an LSST 5-year image. Now, looking at the HIPS images available on RSP, they look the same. Does someone know something about it? (I could illustrate, but I am not sure if it is allowed to share screenshots of the platform here).

Thanks

[MelissaGraham]

Hi @JuliaGschwend, thanks for posting.

For the simulated data from Data Preview 0, it is totally fine to share screenshots (it is not ok to share any real, unreleased commissioning data at this time).

In this case, screenshots of what you’re seeing with the DP0 deepCoadd HIPS images sounds necessary so we can understand what “a bit weird” and “too shallow” means. Perhaps side-by-side screenshot of the HIPS and the deepCoadd would be informative. And knowing which pipeline was run to make the HIPS, and any input configuration parameters that were used, would help too.

[JuliaGschwend]

So, I would expect the 5-year LSST simulation images to show a higher object density (roughly by eye) in comparison with DES DR2 HIPS images. I made screenshots of two levels of zoom (FoV of 1 degree and ~4 arcmin) to compare the HIPS images side-by-side. There may be some contrast control tool that I am missing in RSP. However, the DP0.2 HIPS images created here from the FITS images downloaded from both RSP and NERSC look roughly the same (and they were made using an independent method from those shown on RSP).

[MelissaGraham]

Thanks @JuliaGschwend.

I’d agree that the simulated LSST 5-year deepCoadd images used for DP0.2 should - for roughly the same coordinates (Galactic latitude) - have a higher object density than the DES DR2 (6-year) deepCoadd images, because Rubin’s primary mirror is larger than the Blanco’s. I can understand how the comparison of HIPS maps that you’ve made has raised a concern.

Since there could be other differences between the HIPS images for the real DES and the simulated DP0.2 data, I instead investigated the question of whether the DP0.2 HIPS have a lower object density compared to the DP0.2 deepCoadd images. If so, this would point to something in the DP0.2 HIPS creation process (or the viewer) that causes the discrepancy.

I used the Portal Aspect to query for deeply coadded images that contain the point 62, -37, which is near the center of the DC2/DP0.2 region and not far from the DES coordinates of 32, -27 that you used. Then I visually compared the i-band deepCoadd (left) to the DP0.2 gri HIPS map (right), for two zoom levels (top and bottom).

Above, it does appear that while the DP0.2 deepCoadd images have the object density as expected (similar to or even deeper than DES), the DP0.2 HIPS images do appear shallower than expected.

I’ll take this forward to the HIPS map creators to see get their feedback on this issue. Our internal ticket to resolve this is Jira Issue SP-1772.

[MelissaGraham]

Hi again, I did hear back from the HIPS map creators.

They suspect that when the HiPS maps for DP0.2 were made, the ‘stretch’ parameter, which controls how ‘deep’ the pictures look, was set too loose (too high, too soft). In experimenting with the ComCam HIPS they have since found that a low stretch parameter, something like 0.3-0.5 (a hard stretch) works well for most g-r-i or r-i-z data. The default stretch parameter in hips.py in pipe_tasks is something like 2.0, which gives a very shallow image of the sky, and only the brightest objects stand out. Exactly as you have observed. Given that this sounds like a known issue, I think we can expect to see it resolved in future Rubin-produced HIPS maps.

The first post of this topic mentions that “a pipeline” was run to make a g-r-i HIPS. In light of the information above, re-running it with a harder (smaller) stretch parameter should yield results close to your expectations.

I’m going to mark this post as the solution for this topic thread, because I think we’ve found the culprit here in the stretch parameter. But if this doesn’t quite fix the problem please don’t hesitate to reply, we can keep investigating.