WIP: Add Custom Nebula Textures Plug-in

[ultrapre]

For amateur astronomers to parse their own nebula images and use them as textures.
By inputting photos and Astrometry.net's API to Plate-solve images online, and calculating the four corner coordinates, finally rendering textures of custom nebula images.

The project is work-in-progress, welcome guiding and joining.

Plan:

Initial functional points:

• 1. Online solving.

• 2. Local solving.

• 3. Calculate the RA Dec J2000.

• 4. Goto the identification.

• 5. Render and undo the image.

• 6. Add the image to management.

• 7. Management and deleting.

• usage manual and debug.

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files.

[ultrapre]

@10110111 @alex-w @gzotti Do you have any suggestions for conflicts between custom texture rendering and original texture rendering? Should we let users choose to turn off the original texture and then display the custom texture, or use some algorithm to detect and compare the texture area and then turn off the conflicting texture?

Should it add a json for custom configuration? Or can it directly modify the original texture json and add a key to distinguish between the original and customized ones?

[alex-w]

Please fix compilation of the code

[gzotti]

I am not sure: Can we handle user catalogs independently? There is probably infrastructure for more, but just one "default" nebula catalog. Maybe users could make (manually) a copy of default and then replace whatever they want to replace. Or they just want to use this welcome plugin to then contribute their own images of so far not included DSOs. Given the very latest developments, you need this plugin to platesolve/fit the image with stars, and then apply some de-starring filter to extract the nebula alone. (Unless image is of a cluster of course.)

[ultrapre]

I think it would be cool for astronomical photographers to be able to map their images in the software without having to deal with complex file editing. Rather than just giving developers predefined tools

It would be better to have separate user-defined json and image storage and management, and allow users to choose to hide conflicting original textures (by algorithm).

Another question is that the following formula still has a slight position deviation when calculating the four corners based on wcs fits. Does it also involve the calculation of parameters such as A_0_0, B_0_0, AP_0_0, BP_0_0? Maybe it is related to field of view distortion? I just started to get started, so it would be great if you could help me take a look.

delta_col = x - crpix1
delta_row = y - crpix2
RA = crval1 + (delta_col * cd1_1 + delta_row * cd1_2)  / cos(crval2)
DEC = crval2 + (delta_col * cd2_1 + delta_row * cd2_2) 

[gzotti]

Sorry, will be of no help here. Not my field. For fitting, you may want to disable aberration (to show mean positions). Small-angle (telescope) images should usually be OK, for large images it is not enough to have the corner coords, but need to take lens distortion into account.

[ultrapre]

Perhaps another use is to allow users to analyze their own images and then locate the position in Stellarium, which would be a very practical function

Small-angle (telescope) images should usually be OK, for large images it is not enough to have the corner coords, but need to take lens distortion into account.

This can of course be explained to the user in advance, my plan is that most of the image (within 2-3 degrees) can be displayed accurately

[alex-w]

From the log:

gui/NebulaTexturesDialog.cpp:226:70: error: call to member function 'arg' is ambiguous
   QString contentType = QString("multipart/form-data; boundary=%1").arg(boundary);

Compilation the qt5-based edition is broken

[ultrapre]

wcslib works well for converting pixel to RA/Dec. Stellarsolver is also good for it.
I plan to introduce one of them

New:
Oops, I seem to find the simple formula to solve it, no need for things above.

[ultrapre]

Accuracy of the algorithm as follows:

It works well even at a large scale.

[github-actions]

Hello @ultrapre!

Thank you for proposing of the feature.

[ultrapre]

@alex-w @gzotti @10110111
Sorry, it seems that StelSkyLayerMgr::loadSkyImage is deprecated? The rendering result of the call is different from what I debugged using textures.json. The code of StelSkyLayerMgr and StelSkyImageTile is hard to read and understand for me.

[gzotti]

I fully agree this is hard to read and follow. To me it appears even more features were planned but then not completed.

[ultrapre]

Anyone know how to disable rendering a selected image in the default texture?

[gzotti]

Alexander invented some trick to hide M1 before 1054. Maybe you can go a similar way based on other conditions? Or you will have to add a scriptable function setVisible(QString imgName_or_JSONkey, bool visible). Sorry, I am not enough familiar in this section and would have to study the code again myself.

[sunshuwei]

It is best to have a UI that can manage turning each texture on or off.
Since the Crab Nebula can be turned off under certain conditions, I think perhaps every texture should be able to do the same.

[ultrapre]

The display of M1 is not related to the method of manipulating the display separately, as this also uses the filtering criteria in the data

stellarium/nebulae/default/textures.json

Line 14 in 3c8d3c4

"birthJD": 2106215.0

[gzotti]

If there is no built-in way and you need it, you may need to add a key "visible" which should default to true. Then add the setVisible() command as outlined above. While you are exploring, everything about minResolution and probably other fields need better documentation IMO.

[ultrapre]

Please review the code changes in core.
Does multi-language support only require q_ to wrap the strings that need to be translated?

[alex-w]

Does multi-language support only require q_ to wrap the strings that need to be translated?

Yes, it's enough

[sunshuwei]

Could we consider adding an option in the future that is turned off by default, but can be turned on after consulting with the user, giving the image to Stellarium, using CC BY 3.0 or CC BY 4.0 copyright, and then the official can use these images as materials. It is even possible to develop a community in the future, similar to the Creative Workshop in Steam games, where users can freely choose mods provided by others.

[ultrapre]

Could we consider adding an option in the future that is turned off by default, but can be turned on after consulting with the user, giving the image to Stellarium, using CC BY 3.0 or CC BY 4.0 copyright, and then the official can use these images as materials. It is even possible to develop a community in the future, similar to the Creative Workshop in Steam games, where users can freely choose mods provided by others.

This requires server storage and a multimedia community, although uploading to a designated interface is easy to achieve. Anyway, such functionality can be envisioned in the future, as it is not currently required for this standalone software and the first version of the plugin.

[sunshuwei]

Could we consider adding an option in the future that is turned off by default, but can be turned on after consulting with the user, giving the image to Stellarium, using CC BY 3.0 or CC BY 4.0 copyright, and then the official can use these images as materials. It is even possible to develop a community in the future, similar to the Creative Workshop in Steam games, where users can freely choose mods provided by others.

This requires server storage and a multimedia community, although uploading to a designated interface is easy to achieve. Anyway, such functionality can be envisioned in the future, as it is not currently required for this standalone software and the first version of the plugin.

Yes, this is not required for the first version.

[gzotti]

The current DSO image collection is named "default". I don't know what would have to be done to allow others, i.e. customized lists that could be downloaded elsewhere and installed in a directory next to default. Not sure if it makes really sense to allow user-configuration at the single image level, though. Such collections need to be curated, and it will take a while until, say, 250 images are taken, processed, and configured correctly. I'd like to see alternative collections, though, maybe one collection of sketches through 6-12 inch instruments (to approximate what an observer can expect to see), one with late-19th-century illustrations, early-20th century b/w photos, watercolor and oil paintings, ...

[sunshuwei]

The current DSO image collection is named "default". I don't know what would have to be done to allow others, i.e. customized lists that could be downloaded elsewhere and installed in a directory next to default. Not sure if it makes really sense to allow user-configuration at the single image level, though. Such collections need to be curated, and it will take a while until, say, 250 images are taken, processed, and configured correctly. I'd like to see alternative collections, though, maybe one collection of sketches through 6-12 inch instruments (to approximate what an observer can expect to see), one with late-19th-century illustrations, early-20th century b/w photos, watercolor and oil paintings, ...

Yes, I have always hoped for at least two textures, photographic and visual (with a telescope). This can only rely on the user's ability, there are simple channels, and I think many users are willing to contribute their own strength.
Visual texture may be a sketch or an approximation of black and white photo processing.
However, the analysis of sketches is difficult and coordinates cannot be obtained through astrometriy.net.

[gzotti]

I did not say it would be easy... :-) I have also not looked into the code here now, whether this only platesolves via astrometry.net or allows manual fitting of scanned sketches (where some stars may be off photo-accurate positions). @10110111 made another plugin recently to fit photos. Maybe these could be combined.

[ultrapre]

The current plugin has implemented this feature, allowing users to directly edit coordinates and render effects in real-time, thereby adding the images that cannot be parsed.

For example, an excellent sketch even could be correctly solved and pasted here, but the projection accuracy requirements are too high, so there may still be deviations in the stars. Therefore, I would suggest that hand drawn images need to be preprocessed.

[gzotti]

Yes, sure. I'd first fit (with stars), then remove the stars. Maybe the AI star remover also works here. (It could be wise to also keep "starred" images available. Even as yet another collection?)

[ultrapre]

Yes, sure. I'd first fit (with stars), then remove the stars. Maybe the AI star remover also works here. (It could be wise to also keep "starred" images available. Even as yet another collection?)

For common nebulaes, slight deviations at the arcseconds level are irrelevant. I have been exposed to some deep sky photography, and currently using Siril and StarNet++to remove star points is very convenient. However, this process requires a large amount of computing power, so it is obviously better for users to handle it themselves rather than integrating it into Stellarium.

[gzotti]

Yes, I did not suggest adding a star remover to Stellarium! Just seeing the new star-free DSOs by @sunshuwei , sure that's an external (optional) process. Just that fitting/finding coordinates certainly is easier with stars, even if some are inaccurate.

[sunshuwei]

This PR largely solves Issue #75