Starlight Live and Astrotortilla Screen Capture

[Robrj]

I've been trying to get Astrotortilla working with Starlight Live using the Screen Capture mode.  I can get it to work with Sharpcap (it sees the demo image and attempts to solve).  But with Starlight Live, I get an error at the bottom that says: "Camera Error: CreateCompatibleDC Failed"
 

I've set it up so that it looks for the secondary "Image Display" window using the following settings:

Bottom Margin: 550
Window Class: .*
Left Margin: 20
Right Margin: 680
Top Margin: 65
Window Title: ^Image Display.*

In the "Camera:" pulldown, I've selected "Image Display" from the list.
Binning is set to 1

 

So it's seeing the window, it just cannot start the process to do the plate solve.  I've also tried it with the main Starlight Live window (different pixel settings and window name).

I've tried it with Astrotortilla version 0.7 and the newer 0.8 alpha release with the same results.

I'm wondering if anyone has run across and fixed that problem.  I left a similar post on the Sourceforge site for Astrotortilla.

The only setting I'm not sure about is the "Window Class" setting.  I found the margins of the windows by taking a snapshot of the window and hovering a cursor over the image boundry in Paint (which reads the cursor position in pixels).  I then padded the dimension by 5 pixels so the capture was inside the image window.

 

My current process with Astrotortilla is to save a PNG, convert it to JPG with Paint (Astrotortilla can't see PNG files) and then load it into Astrotortilla with the File load option.  Then it solves fine and moves the mount to the corrected position.   I still need to try a Fits file solve and see if that works.

[Robrj]

So I decided to pursue a different route since there isn't much response on the Astrotortilla Sourceforge site.   I had managed to get it working with Sharpcap on it's test camera image but when I tried it with an actual camera, it gave me the same error.  I just had a thought, I'm wondering if it's a camera pixel area size issue.  The demo image in Sharpcap was much smaller than either my Starlight Live or ZWO camera's  Sharpcap image window.  I'll try a smaller window next time to see if it works.

In the meantime, since Astrotortilla works directly with APT (Astrophotography Tool), and the demo version is free to use,  I downloaded that.  There's an ASCOM driver available through a link on the Starlight Xpress page.   The ASCOM driver was meant for the Lodestar but you can get it working with the Ultrastar as well.  When you install it, install it like it's for a Lodestar.  Then when you connect APT to the ASCOM camera, go into the Ascom Camera properties (pop up dialog box) and change the PID to 505 for the Ultrastar.    I was able to get an image on APT that I can use for plate solving.

In Astrotortilla, I set the "Camera" setting to Astrophography Tool.  Just accept the default and it should be able to capture and solve.  APT defaulted to 8x binning when it first connected.  So I set that to 1x bin and then minimized the program.  You can see it talk to the camera if you leave it up.  A couple of times I had to restart it when it seemed to have a problem connecting.  But once it was connected, it continued to work.  I usually have APT minimized as it's only used to assist with plate solving.

The great thing is that the ASCOM driver doesn't appear to conflict with Starlight Live's use of the camera.

[Robrj]

Here's an update.  It looks like it is a pixel setting issue.  I attempted using SharpCap again and it wasn't working with the screen size settings, giving me the same CreateCompatibleDC error, until I selected a different test camera which was much smaller.  When I lower the resolution in Astrotortilla's screen capture setitngs, it seems to start working again.   So that clued me in that the error had to do with the resolution settings in Astrotortilla.   I'm only testing this with a prior fits image and not live at the moment.  However, the pixel dimensions don't seem to match up with what I'm seeing on the screen in a program like Paint.  So it's not as simple as just doing a screen capture of the image and using those coordinates in Astrotortilla.

 For instance, I made the secondary "Image Display" on Starlight Live the largest it would vertically and set the horizontal so that the image in the window doesn't show a border.  I screen captured that and put it into paint to measure the pixels.  I get an image that's 1300 pixels wide by 1000 pixels high.   But to get Astrotortilla to grab the window and start plate solving without an error, I have to set the window size parameters to 850 wide by 600 tall.  That leads me to believe that it's looking in the upper left quarter of the image window.  But it's possible Paint is not that accurate.  If I decrease the actual window size to 800x600, those parameters don't work anymore and I have to figure out the new parameters.

The way I figure it out is a bit tedious but it's not that hard.  I use Starlight Live's secondary "Image Display" window as the source (Settings Tab, in the "Repeat Image Window" click "Enable").  When it's set to enabled, it will automatically come up the next time you start Starlight Live.  Plus, it saves it's size and position states so it should be the same when it comes up the next time.  That's important because you don't want to have to size Astrotortilla every time the window opened.  Also, it gives me the freedom to adjust the size of the main window without impacting Astrotortilla's settings.  The display title name is always "Image Display" so in Astrotortilla's "Window Title Setting" use " ^Image Display.* " (without the quotes).  That tells Astrotortilla to look for a window with a name that has "Image Display" in it. 

To get the pixel sizes, first I padded the left border by 20 pixels (the secondary Image Display's border is thinner) and the top by 60 pixels.   Then set the right and bottom numbers to something low (e.g. 200 pxels).    Then I pick one parameter and start increasing it until it fails with the CreateCompatibleDC error.  For instance, put the pixel size to 600 and attempt a plate solve.  If it gives me the error, I halve it and try again.  If it passes, I go halfway between those two numbers, etc.  Then when I can get it to start plate solving, I abort and then work on the bottom pixel size using the same method.  Once it does start plate solving, you may notice some parse errors on some lines.  If that happens just reduce the pixel number by about 10 pixels.  I suspect it's seeing the border or something like that.  But it stops when you reduce it.

I still have to try it with a live image.  I'm not certain the fits file I'm using is the same size my telescope would generate as I've used Starlight Live with multiple scopes and it's an older file.  If it works though, I can simplify a lot as I only have to start Starlight Live. 

[Dom543]

Hi Rob,

It is very interesting what you are doing. I would also be interested to be able to have some plate solving done during my real time observing sessions. The other night I spent over a precious hour of aimlessly looking around in the Southern Cygnus - Vulpecula - Sagitta area without finding my orientation. Next day, when I got to the internet and checked with Astrometry.net, it turned out that I mistook the double star Alpha-Vulpeculae for Albireo and that threw me off. Late at night and in the cold brain just doesn't work that well...

If I download Astrotorilla, will that also include the Astrometrics server and data files? And does Astrotortilla work on Windows computers? This far the only option to use Astrometrics without an internet connection was to recompile and/or reassemble the entire package on my computer. And I believe that it was only for Linux and Mac-OS.

Anyway, keep us informed of your efforts. It would be nice to be able to connect Astrotortilla to StarlightLive. But even if it works only with APT, it's better than wasting time on not knowing what we are looking at. If I remember it correctly, APT is ridiculously inexpensive. 

Clear Skies!   --Dom

[Robrj]

Astrotortilla includes everything you need when you install.  It's portion is pretty small.  Cygwin is pretty big and the indexes can be huge depending on which ones you download.  While it utilizes Cygwin like astrometry.net, you don't need to do anything.  It just needs to be there.  When you do an install, it will ask you what parts you want.  You'll need all three for the first install but later if you wanted to add more indexes, you could do the install again and uncheck everything but indexes.

This is the tutorial I used.  It's pretty complete.

http://www.lightvortexastronomy.com/tutorial-setting-up-and-using-astrotortilla-for-plate-solving.html

 

The nice thing about it is even if you can't get live plate solving working, you can still use the file method (take an image, save it, change it to a jpg and load it into astrotortilla).  It will still plate solve and move the scope for you.  It's just a little more involved.  But it works.

[DoctorD]

Hi

I've been using Astrometry.net with SSL and EQMAC under OSx - I've a Python script that looks for the newest PNG file in a directory and and solves locally, you can then SYNC to these new coordinates.

It took a lot of set up as you have to compile Astrometry.net for your system, no packages available however it has been worthwhile as it saves a lot of effort in finding target. You simply slew to the target take a short exposure then solve & SYNC followed by another goto which usually puts the target in the middle of the image.

Ceartainly a great help when remote observing using EAA.

CS

Paul

 

[Robrj]

What they should do is set up a fully configured single purpose virtual machine that you can just download and use.   I think the only hitch would be the indexes as they're intellectual property so they can't be included in a distribution.  But it would save anyone from having to go through the compile route.  They could even set up a script that a user could run to grab the indexes.

[Robrj]

I took the scope out last night to try it out the screen capture mode.  It doesn't seem to want to solve using the screen capture mode.  I can use APT and it will solve and skew the scope.  But when I switch to screen capture mode, it fails to solve for Field 1.  That's with no scope movement after a successful solve with APT.   The whole process is much shorter with screen capture so it's failing early.  It winds up with a "Field 1 did not solve" error and then says "Failed to solve in 3.2s".  It doesn't look like it's attempting to scan through the indexes.  I had a fog roll in soon afterwards.  So I'l need to run down some of the troubleshooting tips on lightvortexastronomy.com.

 

The fact that it's solving with APT tells me that the indexes are fine and probably the camera, filter and exposure time are fine.

[DorsetBlue]

On 14/10/2016 at 15:42, Robrj said:

I took the scope out last night to try it out the screen capture mode.  It doesn't seem to want to solve using the screen capture mode.  I can use APT and it will solve and skew the scope.  But when I switch to screen capture mode, it fails to solve for Field 1.  That's with no scope movement after a successful solve with APT.   The whole process is much shorter with screen capture so it's failing early.  It winds up with a "Field 1 did not solve" error and then says "Failed to solve in 3.2s".  It doesn't look like it's attempting to scan through the indexes.  I had a fog roll in soon afterwards.  So I'l need to run down some of the troubleshooting tips on lightvortexastronomy.com.

 

The fact that it's solving with APT tells me that the indexes are fine and probably the camera, filter and exposure time are fine.

I was trying this (or something similar) for the first time last night. I could not get APT to run with the ASCOM driver for the GPCAM v2 and AT did not seem to like the ASCOM driver too (was getting "requires integer" errors).  So I was resorting to Screen Capture mode using Sharpcap and getting the same result you are, "Field 1 did not solve".  I am going to load the two screen captures I have at the different FL my zoom lens provides into astrometry.net and see what that does with them.

EDIT: As a test, as I am away from my captures from last night - I thought I would run through the GPCAM images I have posted on here in another thread.  All tracked perfectly in astrometry.net and all used the 41xx series of FITS and not the 42xx series I think have been installed by the Astrotortilla installer on my PC.  I will install the 4111 and 4112 FITS files on my PC tonight and see what happens.

[Robrj]

Since I had a good fits file from my last session that I knew matched my current equipment, I loaded it into Starlight Live and then attempted to get the screen capture to work.   I reduced the screen capture size a bit further and it looks like it's started parsing through the indexes but now it's giving me the following error: " Failed to read column from FITS file. "

Researching it a bit, one solution on said to change the downscaling from 2 to 0.  But I'm already at 0.  I believe that solution had to do with reading in a jpg file using the file method.  The conclusion was something about the JPG file was being seen as a fits file and the downscaling number was causing it to fail.  I never had the problem with the screen capture method.  While I was typing this, I had a thought that perhaps bumping the downscaling setting up from 0 to 2 might be a potential fix for the problem.  I'll give it a shot when I get home.

 

Here's the original thread on Astronomyforum.net:

http://www.astronomyforum.net/astro-imaging-forum/146721-need-help-astrotortilla-7-print.html?pp=40