Jump to content

Narrowband

Jocular: a tool for astronomical observing with a camera


Recommended Posts

Thanks Martin for the response and explanations!  From my limited sample, I agree that color balance doesn’t need adjustment, at least not a high priority.  Re exporting the settings -  I only do EEA as well, on an alt-az mount, but it’s nice to share images with friends and family afterwards.  So a little of the AP-wow factor creeps in. 
 

I’m excited about getting Jocular running real time, once I figure out Astroberry.  Definitely more work than the ASIAIR Pro I’m using now.  Thanks for all your work on the tool!

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...
On 31/10/2021 at 17:13, Martin Meredith said:

I'm afraid not. What OS are you running? It is most likely that I'll provide native support for Ultrastar for Macs in the next release if someone is willing to test it.

Martin

Win10, no worries. Thanks for letting me know

Link to comment
Share on other sites

On 31/10/2021 at 11:13, Martin Meredith said:

I'm afraid not. What OS are you running? It is most likely that I'll provide native support for Ultrastar for Macs in the next release if someone is willing to test it.

Martin

Just a thought -- maybe it would be most expeditious to provide an INDI client interface, and let users run the INDI server appropriate to their system (Win, Mac, RPi).  I think I spotted a Python INDI library somewhere.  

Link to comment
Share on other sites

Hi Steve

I looked into pyindi but it is very much Linux-oriented (last time I looked there was a library required that would need rebuilding for OSX).

In fact, I looked at ASCOM, INDI and ALPACA over the summer (from a coding point of view). Personal opinions: I like INDI least. ASCOM was much more 'obvious' but not multi-platform. Both ASCOM and INDI are based on an outdated and verbose protocol (XML), for which reason I think JSON-based ALPACA is the way to go.

But from an application programmer's perspective, what is actually required (in my opinion) is a 'simpleastro.py' that implements the most commonly-used 90% of functionality (move filter wheel, expose for N secs, set temperature, move mount to X, Y; sync mount, and little else) in a way that is cross-platform. This would be a wrapper around some of the above. Those applications that are cross-platform (there are not many of those!) either do this anyway, or transform everything into e.g. ALPACA.

Martin

 

Added in edit: you mention a win-based INDI server. I heard there was such a development some time ago but is it actually realised/maintained/working?

Edited by Martin Meredith
  • Like 1
Link to comment
Share on other sites

1 hour ago, Martin Meredith said:

Hi Steve

I looked into pyindi but it is very much Linux-oriented (last time I looked there was a library required that would need rebuilding for OSX).

In fact, I looked at ASCOM, INDI and ALPACA over the summer (from a coding point of view). Personal opinions: I like INDI least. ASCOM was much more 'obvious' but not multi-platform. Both ASCOM and INDI are based on an outdated and verbose protocol (XML), for which reason I think JSON-based ALPACA is the way to go.

But from an application programmer's perspective, what is actually required (in my opinion) is a 'simpleastro.py' that implements the most commonly-used 90% of functionality (move filter wheel, expose for N secs, set temperature, move mount to X, Y; sync mount, and little else) in a way that is cross-platform. This would be a wrapper around some of the above. Those applications that are cross-platform (there are not many of those!) either do this anyway, or transform everything into e.g. ALPACA.

Martin

 

Added in edit: you mention a win-based INDI server. I heard there was such a development some time ago but is it actually realised/maintained/working?

From what I understand (not much), the primary advantage of INDI is its client-server model.  This allows it to operate remotely (presumably TCP/IP).  I very much like working without a cable to my laptop.  Right now, I use the ASIAIR Pro for all imaging (run via Bluestacks and the Android ASIAIR app), and SMB to access the files for Jocular.   An INDI server is easy to set up on a RPi with Astroberry,  and an INDI client would work nicely with that.  

Agreed, JSON >> XML for this type of application.  If Alpaca supports a client-server model--I see mention at CN of an Alpaca Remote Server--then that would be nice.  

All that said, I'm currently very happy using the ASIAIR Pro for imaging, so this would be very low priority from this user's point of view.  

P.S.:  Don't forget set gain in your simpleastro.py!  🙂

  • Like 1
Link to comment
Share on other sites

I'm curious about how much the stack features (remove sub, reshuffle) get used.  I've tried them with a monochrome camera, and they seem to work well, but I'd probably have to spend extended time with an object to notice significant differences.  

With an OSC, the number of subs grows by three, and LRGB by four.  So the performance degrades correspondingly.  I could try more aggressive binning to avoid this.  But I wonder if the utility of the stack features outweighs this drawback?  I see it would be a major change to the design of Jocular to implement an option to not retain all the subs in memory, but I'm curious about that.

Link to comment
Share on other sites

11 hours ago, Steve in Boulder said:

I'm curious about how much the stack features (remove sub, reshuffle) get used.  I've tried them with a monochrome camera, and they seem to work well, but I'd probably have to spend extended time with an object to notice significant differences.  

With an OSC, the number of subs grows by three, and LRGB by four.  So the performance degrades correspondingly.  I could try more aggressive binning to avoid this.  But I wonder if the utility of the stack features outweighs this drawback?  I see it would be a major change to the design of Jocular to implement an option to not retain all the subs in memory, but I'm curious about that.

I use the remove from stack feature all the time and I believe others do too. Maybe you have excellent tracking and no wind gusts?

Reshuffle is particularly useful to solve stack alignment 'failures'. It comes into its own with LRGB or narrowband+L where there are far fewer stars on e.g. the B subs.

The 70-80-90-median are also useful to get rid of satellites etc

The OSC thing was really just an add-on requested feature from one user to get things going quickly. Jocular wasn't really designed with this in mind. Handling OSC requires a rethink...

cheers

Martin

  • Like 2
Link to comment
Share on other sites

8 hours ago, Martin Meredith said:

I use the remove from stack feature all the time and I believe others do too. Maybe you have excellent tracking and no wind gusts?

Reshuffle is particularly useful to solve stack alignment 'failures'. It comes into its own with LRGB or narrowband+L where there are far fewer stars on e.g. the B subs.

The 70-80-90-median are also useful to get rid of satellites etc

The OSC thing was really just an add-on requested feature from one user to get things going quickly. Jocular wasn't really designed with this in mind. Handling OSC requires a rethink...

cheers

Martin

Thanks, that all makes sense now.  I suppose splitting an OSC file into its components does lose the information that the three components were imaged simultaneously and should align together as is.

I do stay well below the weight limit for my mount (AZ Mount Pro), so it could be that the tracking is solid.  Or just dumb luck.  I’ll have to play with the stack features some more to get a feel for them. 

Link to comment
Share on other sites

10 hours ago, Martin Meredith said:

The OSC thing was really just an add-on requested feature from one user to get things going quickly. Jocular wasn't really designed with this in mind. Handling OSC requires a rethink...

 

Er, um, ... I suppose I take the blame, then?

Fully agree that OSC needs a rethink.  For me, the ideal solution would simply be a separate process which watches files created by the camera software (which I'm very happy with remaining separate, partly because I can dither and auto-focus, and you're not going to put that into Jocular for a while!)   The process would then do the debayering (and possibly binning) of choice and spit out the separate files that Jocular needs. This seems to me to be altogether the cleanest approach.  It would also allow, perhaps, a bit of RGB processing which help with OSC – particularly the suppression of excess green.

I tried the .dev version recently, but, as you say, it's not complete, so reverted to 0.4.5 (it's SO easy - thanks) and have had great fun with it recently, including the use of flats.  I'll post some recent observations shortly.

Tony.

  • Like 1
Link to comment
Share on other sites

1 hour ago, AKB said:

Er, um, ... I suppose I take the blame, then?

Fully agree that OSC needs a rethink.  For me, the ideal solution would simply be a separate process which watches files created by the camera software (which I'm very happy with remaining separate, partly because I can dither and auto-focus, and you're not going to put that into Jocular for a while!)   The process would then do the debayering (and possibly binning) of choice and spit out the separate files that Jocular needs. This seems to me to be altogether the cleanest approach.  It would also allow, perhaps, a bit of RGB processing which help with OSC – particularly the suppression of excess green.

I tried the .dev version recently, but, as you say, it's not complete, so reverted to 0.4.5 (it's SO easy - thanks) and have had great fun with it recently, including the use of flats.  I'll post some recent observations shortly.

Tony.

Well, now you have someone to share the blame with.   I wrote a little Python script to transfer files from the ASIAIR Pro (via SMB) to Jocular's watched directory (the two do not play nicely together in terms of directory and file structure).  It does one bit of optional pre-processing, it can crop the files to create a poor man's version of ROI.   I might look into adding some more pre-processing ability to it.  

  • Like 1
Link to comment
Share on other sites

2 minutes ago, Steve in Boulder said:

I wrote a little Python script to transfer files

My language of choice for scripting is, in fact, Lua.  This rather cuts me out of tinkering with the internals of Jocular, but is perfectly fine for separate scripts like this.  Would be interested, nonetheless, in what functionality you may add to your script.

Tony

  • Like 1
Link to comment
Share on other sites

6 minutes ago, AKB said:

My language of choice for scripting is, in fact, Lua.  This rather cuts me out of tinkering with the internals of Jocular, but is perfectly fine for separate scripts like this.  Would be interested, nonetheless, in what functionality you may add to your script.

Tony

For cropping the images, I use the astropy library (which Jocular also uses).   Don't know if Lua has anything similar.  I can borrow/steal from Jocular code to do de-bayering, at least.  Though I think I'd take on green correction first.  Do you have any pointers to the algorithms one might want?  

Link to comment
Share on other sites

23 minutes ago, Steve in Boulder said:

Don't know if Lua has anything similar.

Lua can link to anything, so I should be able to use that, although you pay the price in footprint of the code.  Lua is tiny, Python is not.

23 minutes ago, Steve in Boulder said:

Though I think I'd take on green correction first.  Do you have any pointers to the algorithms one might want?  

This is really simple.  The algorithm called SCNR...

https://www.pixinsight.com/doc/legacy/LE/21_noise_reduction/scnr/scnr.html

If you invert the image, you can also use this for removing magenta star colour in Hubble palettes, and the like.

Edited by AKB
  • Like 1
Link to comment
Share on other sites

On 05/11/2021 at 11:36, AKB said:

Lua can link to anything, so I should be able to use that, although you pay the price in footprint of the code.  Lua is tiny, Python is not.

This is really simple.  The algorithm called SCNR...

https://www.pixinsight.com/doc/legacy/LE/21_noise_reduction/scnr/scnr.html

If you invert the image, you can also use this for removing magenta star colour in Hubble palettes, and the like.

I don't know very much about image processing, is the following correct?  To apply this algorithm, I have to debayer the image first.  Then use the algorithm on each pixel per pixel.  Then, to operate with Jocular, I'd have to mimic what it does with unprocessed OSC images, creating L, R, G, and B image files from the debayered, SCNR-corrected file and feeding them to the watched directory.  To Jocular, it should then look like these are individual frames coming from a filter wheel.  

Link to comment
Share on other sites

Essentially correct.  You don't need to synthesize an L file – Jocular will do that internally itself.

You can, no doubt, use the Jocular library for debayering, but the simplest approach is to use "super-pixels", which essentially use a 4x4 matrix (typically of RGGB) to generate a single (RGB colour) pixel, thus binning the image x2 at the same time.  This is quite effective for modern CMOS OSC which tend to have small pixels and too many of them for Jocular to be entirely comfortable (in terms of operating speed.)

Edited by AKB
  • Like 1
Link to comment
Share on other sites

In case it helps, I use the colour_demosaicing module for debayering. It comes down to just 2 lines of code:

from colour_demosaicing import demosaicing_CFA_Bayer_bilinear
rgb = demosaicing_CFA_Bayer_bilinear(im, pattern='RGGB')

where im is the 2D image to debayer, and pattern can be any of the usual colour pixel configurations. rgb is a N x M x 3 array.

For binning/super-pixels as Tony describes you can use either rescale (for non-integer interpolation) or downscale_local_mean (for what we normally understand as binning i.e. downscaling by integer factors)

from skimage.transform import rescale, downscale_local_mean
rescale(im, 1 / binfac, anti_aliasing=True, mode='constant',  preserve_range=True, multichannel=False)

or  

downscale_local_mean(im, (binfac, binfac))

Martin

  • Like 1
Link to comment
Share on other sites

20 hours ago, Martin Meredith said:

In case it helps, I use the colour_demosaicing module for debayering. It comes down to just 2 lines of code:

from colour_demosaicing import demosaicing_CFA_Bayer_bilinear
rgb = demosaicing_CFA_Bayer_bilinear(im, pattern='RGGB')

where im is the 2D image to debayer, and pattern can be any of the usual colour pixel configurations. rgb is a N x M x 3 array.

For binning/super-pixels as Tony describes you can use either rescale (for non-integer interpolation) or downscale_local_mean (for what we normally understand as binning i.e. downscaling by integer factors)

from skimage.transform import rescale, downscale_local_mean
rescale(im, 1 / binfac, anti_aliasing=True, mode='constant',  preserve_range=True, multichannel=False)

or  

downscale_local_mean(im, (binfac, binfac))

Martin

Thanks, Martin!

Link to comment
Share on other sites

  • 2 months later...

yes, and yes 🙂

The native ASI support is all there (I've been using it for a week or so with my new ASI 290mm) but I need to add the extra gain/offset/ROI params into the calibration-handling part so that the automatic calibration does the right thing. I expect to be able to release the next version next week.

Martin

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

The new release of Jocular is now available. 

This is a major new version which supports ASI cameras natively across the 3 major operating systems. ROI/binning are supported for ASI cams, and the calibration library applies automatically to ROI-ed images. There are changes to the GUI to incorporate material design widgets, silent logging, easier installation and a host of other small changes including being able to change the location of the watched directory, though nothing major in terms of processing or object databases. Oh, and it has (annoying) tooltips for which the most important information is probably how to switch them off (conf/Appearance...).

For further details, see:

https://transpy.eu.pythonanywhere.com/jocular/

The download (~29M) now comes bundled with a couple of example captures.

I've developed and tested this on OSX using an ASI 290MM. I haven't been able to test on Windows but in theory it ought to work.

Please let me know (I'm sure you will!) of any issues 🙂

Martin

PS There is also (highly) experimental native support for the SX Ultrastar which I haven't been able to test, so any feedback from Ultrastar users on Macs would be appreciated (pretty sure this won't work on Windows but who's to say). Similarly untested is ASCOM filterwheel control. I'm planning to support ASI filterwheels in the near-ish future.

  • Like 5
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.