Ah, I was playing around with CodeLite on the Raspberry. I saw C under GTK.

But very nice Marc!

Yes! I just wanted to formalize the procedure so we could imagine an assistant.

@Marc2b: Could you formalize how you expect the circles to extend or shrink? Is there a relation with aperture? How would you manage elongation, and what information would you gain from it?

-Eric

I'm not a fan of this living on the focus tab, unless you can save your settings and reload them. So much room for error if you don't forget to put it back the way it was. I lose whole nights of imaging when focus goes bad.

I would concur with Andrew about probably needing a new home (tab) that goes beyond the issue of putting focus tab settings back. Should we be considering a "collimation" tab? If you think about what features might be included in time, one could imagine a looping track control for the out-of-focus image, concentric circles, metrics for WFE quality, and potentially inward focus/outward focus comparision. An aid for the collimation screws/direction to adjust could be even longer term desirable.... I think a collimation tab might prove useful.

Ok this is a test run...

So, you start sct-colim, then adjust the size of the window so the outer ring fits the exterior brim of your donut.
Then you use the left click/right click to adapt the size on the inner ring to the circle of the secondary mirror. (wheel mouse in the dark... not good, too easy to roll it unwillingly). And you can change the colour (RGB) with the central click. Window is always on top.
Program is x86_64. Haven't tried to build it on a raspi so far. Hope for clear skies tonite.
Please test it if you can. I'll publish the source as soon as everything is OK. You need GTK+2.0 GDK and cairo libs installed.

- Marc

I assume you mean we should do: sudo apt-get install libgtk2.0-dev

I did and was able to build and execute the sample Codelite GTK 2.4C.

First real life test... Sure it's a bonus ...

- Marc

Agreed on the subject of settings. I've got yet another code branch on my computer that provides settings serialization for all tabs, that is, saving and loading tab settings to XML files. Not complete yet, no...

However, we need to keep the amount of tabs minimal. Right now we have:
- Manager, responsible for editing profiles, and starting the INDI server and drivers.
- Scheduler, responsible for orchestrating observation sessions.
- Mount, responsible for pointing and monitoring the telescope movement.
- Capture, responsible for exposing one, eventually filtered, optical sensor.
- Focus, responsible for moving the sensor to the optimal focus plane.
- Align, responsible for resolving the position of the telescope.
- Guide, responsible for keeping sensor pixels illuminated by the same sky spatial angle.
- Observatory, responsible for ensuring safe operation of the observation setup.

The next tabs that could appear are a log analyzer and a storage manager. Whatever feature we create, we need to find the best location where to insert it: if a collimation helper is created, then its best location is clearly the Focus module currently.
When development progresses and that helper takes so many settings that it doesn't fit the Focus tab anymore, then, agreed, it should move out. Frankly, right now, most of the features are already covered by Focus.

Unless we get much help, Ekos cannot achieve the same level of specialization as SkyGuide or CCD Inspector. But some neat things can be done.

That's why I listed the steps of the procedure that best fits the OP requirement, in order to find where elements should be fixed, improved or automated. I understand that:
- altering settings with no way to return to stable values is a BIG problem for many of us.
- the cross-hairs overlay should be configurable, and/or should fit star properties detected in the sub-frame.
- process automation would be desirable, in the same way as the polar alignment tool.

Any other ideas?

-Eric

I'm thinking there needs to be a way to invoke interfaces that are not regularly used in an imaging session but could borrow from components that are already built. Maybe just make it a button on the Camera tab to launch a collimation interface that borrows heavily all the correct components.

This would be similar to the mount model feature on the align tab.

I agree the best place is in the focuser tab. That seems obvious as you need to focus in/focus out along the process
(i.e you need to test extra focus AND intra focus, if the difference is important, it could mean your Shmidt blade is misaligned).

I think you need to deal with the two circles (one for the outer ring and one for the inner ring) separately. At least it's what I have done...
How you do this is not really important, this is trivial to program..

I think The process should be linked in a way or another with autoguiding. Trying to collimate an SCT (most particularly the longest ones)
without autoguiding is just futile.

I also think we could have 2 presets :
- One fast fps 100/300 mlsecs and high gain for "ordinary" nights.
- One slow fps 1000->3000 mlsecs low gain for high turbulences nights.

For elongation, I have no (simple) idea. The simplest way is probably to put the test star in the middle of the field.
Remember some SCTs are corrected, other not, if you have in mind to test both the center and the edges ...

- Marc

Source of sct-colim if you have basic skills in compilation and can't wait ...

- Marc

I have it running... but it's not transparent. The circles resize nicely and change colors. (pretty neat)

Now what I did was replace the sample main.c that is auto built by CodeLite. It's an Executable GUI GTK 2.4/C project.