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. (Deferred)
• 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?

Files matching guide/**:

• Did you remember to update screenshots to match new updates?
• Did you remember to grammar check in changed part of documentation?

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.

[ultrapre]

NebulaTextures Plugin Test Report Outline

1. Functional Testing

• Follow guide steps: ✅ Passed
• Different datasets (Astrophotography/Hand-drawn images): ✅ Passed
• Polar images: ✅ Algorithm validated
• Cross-equatorial and cross-meridian images: ✅ Algorithm validated
• File management: ✅ No invalid images left
• Restore default: ✅ Passed

2. Negative & Boundary Testing

2.1 Invalid Operation Steps

2.2 Empty Input & Length Limits

• Invalid file path : ✅ Handled
• Multi-language filepath support: ✅ Supported
• Invalid API key: ✅ Login request handled
• Invalid coordinate format: ✅ Bounded within -90~90, 0~360

2.3 File-related Issues

• Invalid file type ✅ (Basic extension filtering, actual format verified via network parsing)
• Invalid image ✅ (Determined via network parsing)
• File size limit: ❓ No restriction set
• Image flipped: ❌ No image editing functionality, unhandled

2.4 Network Response Errors

• Disconnecting network during parsing: ✅ Retry limit & cancellation implemented

3. Performance Testing

3.1 Frequent Uploads

• ✅ UI restriction applied

3.2 UI Responsiveness

• ✅ Rapid button clicks

4. Compatibility Testing

4.1 Cross-Platform Testing

• ✅ Windows 11 21H2, Qt 6.8.1 MSVC2022 64-bit

• ✅ Ubuntu 24.10-desktop-amd64, Qt latest

• ✅ MacOS 14.0, Qt 6.9.0 Desktop

4.2 Installation Testing

• ❌ Not conducted

5. Security Testing

• ✅ API key visibility settings
• Configuration stored in plaintext: ❌ No security measures applied

6. Regression Testing

• ✅ No issues after rebase

[ultrapre]

Changelog

• GUI changes readable
• Log output format fix
• Restore functionality
• Corrections based on the test checklist
• Brightness control
• Double-click centering
• Cancel solving function
• Multi-system testing

GUI Form

[ultrapre]

While you are exploring, everything about minResolution and probably other fields need better documentation IMO.

The minResolution at the top of textures.json controls the visibility and FOV relationship of all textures (equivalent to sub textures) within it. Therefore, the minResolution value of each image does not work because each texture has no sub-images.

[sunshuwei]

I adjusted the minResolution values using two adjacent images on the celestial sphere, both textures being 1024x1024. TextureA.png was set to 0.02 and textureB.png to 1.0. When zooming in on the screen, textureB.png would appear first. If we swap the minResolution values - setting textureA.png to 1.0 and textureB.png to 0.02 - then textureA.png would appear first instead.

[gzotti]

Impressive work!
Also thanks for documentation. I guess it makes chapter 8.2 obsolete.

A few usage points:

• You should probably make a menu button with a clear icon. Going over config dialog/plugins/config each time is cumbersome.
• I tried with two images. After solving, the lower "Rendering debugger" could be more intuitive:
  -- just one checkbox could be used to "render"/"stop render". Or is there a reason for the two buttons?
  -- The Bright/Normal/Dark should emit a signal with new setting, so that a redraw at the correct brightness is initiated.
  -- I don't know what "Disable default textures" should do. The built-in DSO texture is still visible.

Ah- this is active only after restart of Stellarium! Also the option so the second tab. You could add tooltips or a label to tell the user that newly added images need a program restart to become fully usable.

Does the brightness control set the maxBrightness entry in the json?

[gzotti]

A tiny fix for the User Guide:

[ultrapre]

• You should probably make a menu button with a clear icon. Going over config dialog/plugins/config each time is cumbersome.

For Showing only?

• I tried with two images. After solving, the lower "Rendering debugger" could be more intuitive:
  -- just one checkbox could be used to "render"/"stop render". Or is there a reason for the two buttons?
  -- The Bright/Normal/Dark should emit a signal with new setting, so that a redraw at the correct brightness is initiated.
  -- I don't know what "Disable default textures" should do. The built-in DSO texture is still visible.

Ah- this is active only after restart of Stellarium! Also the option so the second tab. You could add tooltips or a label to tell the user that newly added images need a program restart to become fully usable.

Good advise, all fixed.

Does the brightness control set the maxBrightness entry in the json?

Yes.

[gzotti]

• You should probably make a menu button with a clear icon. Going over config dialog/plugins/config each time is cumbersome.

For Showing only?

Yes. Most plugin dialogs can be called up via bottom-menu button. Click once to activate, another time to hide. Usually these plugin draw some extras. A separate dialog (usually the respective PluginConfig dialog) can be called via right-clicking. Your plugin also has a drawing aspect and a GUI aspect. Actually, the menu button could toggle "show my own images" while right-clicking could toggle the editor dialog.

...
Does the brightness control set the maxBrightness entry in the json?

Yes.

While I was testing, the underlying (existing) image could not be switched off, so images visually merged but I saw "dark" added some resolution. After restart I could toggle visibilities of the default and my own image, however I had set it to "dark", and all by itself it was too dim now. You could add a section to the User Guide about the created JSON file in modules/NebulaTextures, where the maxBrightness value (or others, minResolution, ...) could be manually adjusted to peoples' needs. At this point you may know more about these numbers than the current maintainers. Documenting helps not forgetting!

It is not necessary (but would be just awesome...:) to manipulate the displayed brightness interactively in the GUI. I know, there are always more ideas than time, but some grim ugly rainy winter days can be also spent in useful ways... :-)

[ultrapre]

While I was testing, the underlying (existing) image could not be switched off, so images visually merged but I saw "dark" added some resolution. After restart I could toggle visibilities of the default and my own image, however I had set it to "dark", and all by itself it was too dim now. You could add a section to the User Guide about the created JSON file in modules/NebulaTextures, where the maxBrightness value (or others, minResolution, ...) could be manually adjusted to peoples' needs. At this point you may know more about these numbers than the current maintainers. Documenting helps not forgetting!

It is not necessary (but would be just awesome...:) to manipulate the displayed brightness interactively in the GUI. I know, there are always more ideas than time, but some grim ugly rainy winter days can be also spent in useful ways... :-)

The existing underlying texture makes it difficult for users to accurately judge brightness, so I plan to set "Disable Default Texture" as checked by default.

The three values in the brightness dropdown are set based on my experience, and they should be sufficient for most texture scenarios. Would allowing users to freely adjust an empirically determined value—one that is inherently difficult to fine-tune—actually make the results less reliable?

Of course, providing a description in the user manual is necessary.

[ultrapre]

Change:

You should probably make a menu button with a clear icon. Going over config dialog/plugins/config each time is cumbersome.

Added an "Enter" button

used signal mechanisms to refresh the texture drawing during the operation to control region conflicts

completed the disabling of the default texture option during texture testing

[gzotti]

Tried another photo.
I had previously pressed "remember me" for the Astrometry.net APIkey. The entry box was empty, though. I think it should appear filled with the stored APIkey (hidden chars) and checked box "remember me".
Unfortunately solving failed. Not sure if the service was down or overloaded? Log message is just

[NebulaTextures] subid "0"
[NebulaTextures] Failed to get submission status.
[NebulaTextures] Failed to get submission status.
[NebulaTextures] Failed to get submission status.
[NebulaTextures] Failed to get submission status.

Of course I filled the API key as copied from astrometry.net.

[ultrapre]

[NebulaTextures] subid "0"

The subid should not be "0". This is because you did not set a valid API key.

[gzotti]

OK, this works again, thanks. Now, the result was not perfect, and I tried to tweak the corner coordinates.

• The left and right are inverted. (RA goes from right to left!)
• Changing the coordinates (with MouseWheel) does nothing on screen. I have to "Stop test" and "Test this texture" to redraw at the new position or with new corners. The texture coordinate spinboxes emit a "valueChanged" signal which you could receive and redraw immediately to make the changing an interactive experience.
• If user messes around too much, a "Reset to solution" could then place the new image where astrometry.net had estimated.
• You can utilize our derived GUI class, AngleSpinBox, for more user-friendly coordinates. (And you can make DisplayFormat selectable for everybody's taste.)

[alex-w]

@ultrapre is it possible to fix Georg's suggestions up to end of current week?

[ultrapre]

@ultrapre is it possible to fix Georg's suggestions up to end of current week?

Okay I'll find time to finish it as soon, sorry for a little bit busy lately = =

[alex-w]

Okay I'll find time to finish it as soon, sorry for a little bit busy lately = =

No problem, it just need planning the version of Stellarium to including of the plugin - 25.1 or 25.2