Plate solve issue

[brisguy]

As first reported here: viewtopic.php?f=23&t=4500

I think there is something wrong with plate solve, at least with SvBony SV305. This does not happen all the time, but frequently. SC4 reports a huge number of sources before trying to solve. Normally, this results in a failure to solve. I don't know if this solve failure happens every time since it takes several minutes. The workaround is to lower the gain and exposure to get the sources down. At this point, the image is basically black with only 2-3 visible stars. Only when using the histogram stretch is anything visible. Normally, to get a good image for plate solving, I have to see at least a dozen stars without histo stretching.

I saved two files from images that reported large numbers of sources - see attached. I also attached the capture specs. Files are marked with the reported source number. When I used the files as sample images for the test camera, the 957 image solved fine with, I think 22 sources, and the 1051 file failed to solve with 2 sources. I also attached the log file for the time when I was capturing these images and trying to solve.

[admin]

Ah, I see, you shared the images here - I spotted your post in the other thread first. Hold on...

Robin

[admin]

Hi,

did you have to reduce the image quality or size of those images in order to upload them? I have downloaded them, but when I test them with the same sigma settings as you (50), I get 22 sources from the '957' file and only 1 from the '1051'. I have to lower my sigma value to between 5 and 10 to get the sort of counts you are getting. I'm just wondering if reducing the file size for upload has wiped out some of the noise in the image (which was possibly being detected as stars in your tests).

cheers,

Robin

[brisguy]

> I get 22 sources from the '957' file and only 1 from the '1051'.
Exactly. That is my point. When I captured those images, Sharpcap reported those high source counts, but when I save the images and analyze them later, I see a much more reasonable number. I did not modify the images before uploading.

The problem with this issue is repeating it. Sharpcap (or asvr) gets in a mode where it appears to be preprocessing the image in a way that produces those strange results and plate solving stops working. I assume it must be something unique to my setup or others would be complaining about this. However, it happens to me almost every time I try to use plate solve - but this has only been a handful of times since I just started using ASCOM to control my mount. I have seen others complaining about high source number though.

I am happy to try other things to document this when it happens if you have suggestions.

[admin]

Hi,

definitely weird...

can you try to snatch a copy of the actual frame used for plate solving - this gets saved to your temp folder and should be there while the solving is happening. SharpCap logs the file name, but if you delete all the existing stuff in your temp folder then spotting a new PNG file appear should be easy

Code: Select all

Info   	21:09:40.834539	#1 	Writing capture settings file to C:\Users\User\AppData\Local\Temp\tmp47B.tmp.png.CameraSettings.txt						in void SharpCap.Models.Camera.WriteCaptureSettingsTextAndHistogram(bool writeHistogram, string filename, string contents)
Debug  	21:09:40.837672	#1 	Notification (Status=OK): Snapshot captured to C:\Users\User\AppData\Local\Temp\tmp47B.tmp.png							in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)

That means we would have the exact file that is being fed to the plate solving engine, and further down the log we have a list of the parameters that are sent

Code: Select all

Info   	21:09:41.325131	#1 	Astrotortilla plate solve command is: solve-field -b /etc/astrometry/backend.cfg  --ra 2.53702083327161 --dec 59.2795138888889 --radius 15 --sigma 50 -r --objs 100 --no-plots -N none -L 0.1 -H 20 -u degwidth -D /tmp/c234e6ad-24d4-46dd-bd23-81bbc209ecb3 /tmp/c234e6ad-24d4-46dd-bd23-81bbc209ecb3/frame.png
				in async Task<SolveResults> SharpCap.ImageProcessing.AstroTortillaPlateSolver.SolveImpl(string imageFile, RADecPosition approxPosition, CancellationToken cancellationToken, double searchRadius, double minScale, double maxScale)

Note that by this point, SharpCap has copied the temp PNG file to 'frame.png' in a suitable place for the plate solver to read it. Anyway, with all that info it should be possible to recreate the plate solving run exactly.

cheers,

Robin

[brisguy]

OK, will do. I suspect they will not be any different than what I already provided. But won't know until I try. May be foggy/cloudy/smoky for several days now, but I'll try to get out there soon!

[admin]

Hi,

I know what you mean, but somewhere, something is different between the original plate solving results and our attempts to recreate them. Finding the difference is going to be the key to understanding what is going wrong. We've looked in the obvious places and come up without any answers, so we have to start looking in the places where you think 'it can't be that' until it turns out that it is...

cheers,

Robin

[brisguy]

Was able to get out last night and ran into mega sources problem right away. I do have the png file used by the plate solver, but it is larger than 1MB, so I can't attach. How can I share it with you?

Spoiler alert: The log shows the file had 990 sources. When I load that file as a test image, it fails to solve with only 10 sources.

BTW - I used exactly the same camera settings as used for polar align and that worked great. Solving in milliseconds.

[admin]

Hi,

feel free to email the file to me - I will send you a PM with the email address, although it is easy to guess

I wonder if it is the fact that you are using the camera in 12 bit mode? By default when you load a file as a test camera image it will use only 8 bits of data, which would possibly explain the different results.

cheers,

Robin

[brisguy]

>By default when you load a file as a test camera image it will use only 8 bits of data, which would possibly explain the different results.

This might explain the difference between the source number during use and then later analysis, but does not explain why the number of sources seems to vary so wildly and abruptly - making plate solve unreliable for me. HOWEVER - recently, since I run into the problem so often, I stopped fighting it and just reduced my exposure and gain to something I thought would be ridiculously low and plate solve is suddenly reliable! The only problem now is that I can't use those settings for anything else, but I finally started to use Capture Profiles so saved a 'Plate Solve" profile which is:
1 sec, gain 72, 12-bit, full res. The gain was set by trial and error.

When I look at the capture display, it is completely black and I have to view using histogram stretch in order to see any stars. But this setting works consistently with plate solve sigma set to 90. I typically get between 50-100 sources and it typically solves in less than one minute.

So should I be using 8-bits when I am trying to plate solve?