Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect moon terminator? #973

Closed
Atque opened this issue Feb 14, 2020 · 13 comments · Fixed by #502
Closed

Incorrect moon terminator? #973

Atque opened this issue Feb 14, 2020 · 13 comments · Fixed by #502
Assignees
Labels
bug Something likely wrong in the code importance: medium A bit annoying, minor miscalculation, but no crash
Milestone

Comments

@Atque
Copy link
Contributor

Atque commented Feb 14, 2020

I tried a 300 mm lens the other day. With it, I photographed the moon. This photo is from 2020-02-12 23:11 UTC+1, at latitude +58° 16′ N, +11° 27′ E.
moon

Compare this photo to the moon in Stellarium:
stellarium-014

You can see that both the craters Keldysh and Atlas are illuminated in Stellarium, but not in reality (the two craters north of Hercules). I don't know if this problem lies within the normal map of the moon, or the model of the terminator. Or perhaps linked to the rotation model of the moon?

A bit nitpickish perhaps. :) But I noticed this problem when I tried to use Stellarium to name craters from the photo I took.

@gzotti
Copy link
Member

gzotti commented Feb 14, 2020

I have made many photos of the moon. Exposure time can make a big difference! If you overexpose, you may see some craters in what is now dark.
Another factor can indeed be the imprecise rotation model. #502 should fix that.

@gzotti gzotti linked a pull request Feb 14, 2020 that will close this issue
@gzotti gzotti self-assigned this Feb 14, 2020
@gzotti gzotti added state: in progress The problem is in process of solution... importance: medium A bit annoying, minor miscalculation, but no crash labels Feb 14, 2020
@gzotti gzotti added this to To Do in Astronomical calculations (AstroCalc) via automation Feb 14, 2020
@gzotti gzotti added this to To Do in Solar System via automation Feb 14, 2020
@Atque
Copy link
Contributor Author

Atque commented Feb 14, 2020

Hm, yes, exposure might be a possible answer here. This photo was taken with 100 ISO, 1/50 s exposure at f/5.6. Using higher ISO and shorter shutter speed made the moon too grainy to make out finer details. 300 mm lens might not be enough to test this thoroughly.

Maybe I should try Nikon P1000 that my collegue has...

@gzotti
Copy link
Member

gzotti commented Feb 14, 2020

Try 1/15s and 1/2s for comparison. This will burn out the bright part, but may add more craters on/behind the terminator. I must admit, it is decades ago that I had much fun in the darkroom selectively shading parts to get a better-balanced print. Now one would mosaic together differently exposed images. We hope to show illuminated craters when they are visible in a telescope, not how they appear in a photo. The brightness is surprisingly hard to get right.

@Atque
Copy link
Contributor Author

Atque commented Feb 14, 2020

Yes, the sights of a human eye is very hard to simulate on a computer screen. I can try to compare with different shutter speeds once the weather gets better. Unfortunately, the moon is visible in the early hours at the time. :/

@gzotti
Copy link
Member

gzotti commented Mar 18, 2020

@Atque any new photos?
It's not even the human vision, it's a single photo which is hard to simulate. If I make a well-exposed bright part, the terminator will be too dark and some craters are not visible. If I expose those correctly, the well-illuminated part of the lunar disk will be burnt out. Been there, done that. When observing at the eyepiece, our vision can concentrate on the foveal spot, and over-/underexposure is just "imagined away".

@Atque
Copy link
Contributor Author

Atque commented Mar 19, 2020

@gzotti Sorry, I haven't had the opportunity to shoot any more photos. I will try to borrow my colleague's Nikon P1000 to compare long vs short exposure times.

BTW: This is a nice website that may help when comparing the new rotational model to "official" values:
https://svs.gsfc.nasa.gov/4768

@Atque
Copy link
Contributor Author

Atque commented Jan 16, 2021

@gzotti I built your branch, and it seems the terminator i aligned better. I think the PR will close this issue. Look at this GIF comparing the old and new rotation model:

moon_old_vs_new

@gzotti
Copy link
Member

gzotti commented Jan 16, 2021

Thanks for the confirmation. Yes, the old version only had a simple rotation, now I apply multiple corrections, and comparing also numerical libration results to reference solutions shows that we now should have a good solution.

@Atque
Copy link
Contributor Author

Atque commented Jan 16, 2021

It's really nice to see Stellarium is taking huge leaps toward 1.0. Now "all" we need for the Moon is a better texture, because the current one is quite ugly, to be frank.

@gzotti
Copy link
Member

gzotti commented Jan 16, 2021

At least one huge leap, indeed. This one was surprisingly hard, and I needed to find time slots to work on it for days in succession.

You can activate a HiPS texture layer for the moon, but this has still its own problems with its normal map. The current overall limitation to 2048x1024 texture files is a concession to a large legacy platform of old hardware. But indeed, the current texture has its issues with e.g. a dark Clavius. There are higher-res textures on the web to use instead. Can you help us identify good textures 16384x8192 (or at least 8192x4096) for color and normal maps which we could offer instead? (License considerations are important!)

@Atque
Copy link
Contributor Author

Atque commented Jan 16, 2021

@gzotti The licensing is the most difficult part. We have the texture linked here, that looks really nice (yes, even for high latitudes):
https://github.com/briligg/Moonwards-Assets/tree/master/Models/constructs/Planets/Moon/textures

When used in Stellarium in 2k res:
stellarium-052

I have no idea about the licensing though. The normal map in the default Stellarium package seems fine, at least it looks good when I use it.

Solar System automation moved this from To do to Done Jan 16, 2021
Astronomical calculations (AstroCalc) automation moved this from To do to Done Jan 16, 2021
gzotti added a commit that referenced this issue Jan 16, 2021
* Accurate planet axis orientation and rotation   (Fix #151, Fix #347, Fix #357, Fix #358, Fix #1261, Fix #877, Fix #973)
- Finally finished this long-duration work 2016-21
- Using data from WGCCRE reports 2009, 2015 and Explanatory Supplement to the AA 2013 (with error fixed by the 1992 ed.)
- Keeps original Stellarium planet rotation model (undocumented) where new rotation elements are unavailable
- Slight restructuring of Planets, Comets, MinorPlanets, SolarSystem loader.
- Add lines for the Invariable Plane and Projected Solar Equator
- Add solar altitude to planetary feature nomenclature
- SUG: Describe planetary coordinates and changes in the nomenclature display.
@gzotti gzotti added this to the 0.21.0 milestone Jan 16, 2021
@alex-w alex-w added bug Something likely wrong in the code state: fixed The bug has been fixed and removed state: in progress The problem is in process of solution... labels Jan 17, 2021
@github-actions
Copy link

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

@alex-w alex-w removed the state: fixed The bug has been fixed label Mar 28, 2021
@github-actions
Copy link

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something likely wrong in the code importance: medium A bit annoying, minor miscalculation, but no crash
Development

Successfully merging a pull request may close this issue.

3 participants