Capture software for Linux

[StuW]

There is some source on Github for the Beagleboard with same sensor https://github.com/Aptina/BeagleBoard-xM/blob/master/MT9M034/Angstrom/mt9m034.c  might be of help.

[AlexB67]

Guilty as charged, I'm afraid

I did actually start out on UNIX using something other than vi, but I can't recall what it was off the top of my head.  Then I got into uEmacs, but when I left university I was working on a large range of different UNIX boxes and vi was the only editor guaranteed to be present on all of them so that's what I used and I have done so for the last 25 years.  Now vim does useful stuff such as syntax highlighting I've not seen a compelling reason to change

I don't know how much of a following Emacs still has.  I did know people at university (this was back in the days of 80x25 terminals, before most people had access to a machine with a GUI) who had emacs set as their login shell.

I recall writing my thesis with  some windows version of vim at the time using ( tex/latex ) on a 286 with 64 kB RAM, it was the only thing light enough I could use from home and could handle a document of that size and compile it to a processed dvi , and it handled it with a breeze. Word perfect or whatever word processors were around even on a 386 would just fall over in those days with documents of that size. Vi was so fast that even doing a search and replace in several hundred pages was instant, I am reminiscing now, but those were the days compared to the grinding of some of the bloatware of today :0)

Edited September 26, 2013 by AlexB67

[JamesF]

I recall writing my thesis with  some windows version of vim at the time using ( tex/latex ) on a 286 with 64 kB RAM, it was the only thing light enough I could use from home and could handle a document of that size and compile it to a processed dvi , and it handled it with a breeze. Word perfect or whatever word processors were around even on a 386 would just fall over in those days with documents of that size. Vi was so fast that even doing a search and replace in several hundred pages was instant, I am reminiscing now, but those were the days compared to the grinding of some of the bloatware of today :0)

Yes, I think Moore's Law applies to software, too  Computing power might double every eighteen months, but software bloats to consume most of the additional resources.  Total functionality doesn't grow that much at all

James

[AlexB67]

Yes, I think Moore's Law applies to software, too  Computing power might double every eighteen months, but software bloats to consume most of the additional resources.  Total functionality doesn't grow that much at all

James

So often true, Signed and rubber stamped

[JamesF]

There is some source on Github for the Beagleboard with same sensor https://github.com/Aptina/BeagleBoard-xM/blob/master/MT9M034/Angstrom/mt9m034.c  might be of help.

I have a feeling that doesn't help, from memory.  One or the other camera is connected up via an I2C interface if I recall correctly, whilst the other isn't.  I may be completely misremembering that however.

James

[JamesF]

It would be nice to see the SPC900 properly supported again. In order to control it my 'field' laptop still runs Ubutnu 10.04.........

Actually Alan, as I have most of the controls working this evening, I could punt the binary over your way if you want to give it a whirl to see if you get anything on-screen.  It will be useless for anything else, but you might at least be able to test the camera to see if you can get it to work on Mint 15.

James

[JamesF]

Well, I may have most of the camera controls working, but the last two are proving a bit of a pig.

It looks like either the SPC900 driver or the V4L2 layer doesn't allow the frame size or frame rate to be changed once a camera has been started.  Even stopping the camera streaming data and changing the values doesn't seem to help.  Looks like I might need to close and re-open the device if the resolution or frame rate changes.  But that's something to play with tomorrow.

James

[AstroTux]

Actually Alan, as I have most of the controls working this evening, I could punt the binary over your way if you want to give it a whirl to see if you get anything on-screen.  It will be useless for anything else, but you might at least be able to test the camera to see if you can get it to work on Mint 15.

James

James, that would be a great idea.

I've tried cheese and it works with the camera, but the necessary control is not there. User and factory settings cannot be restored with wxAstroCapture using V3 of the Linux kernel, and things such as frame rate, gain, etc. do not work at all. This is a shame as I had previously loaded the macros provided by Martin Burri, et al, into the camera from a windows system, and everything worked using V2 kernels.

If you would like me to test it you can send it to alan@alanlmilne.co.uk . Just one small problem though, as always I am just about to embark on another of my walking holidays ( tomorrow morning ) followed by a couple of days at the Sixpenny Handley star party, so it may be a week or more before I can let you know the outcome.

Hope this helps, all the best,

Alan

ps. whilst typing this the T-ring for my Canon EOS has just popped through the letter box, but it won't stop me wanting to use the SPC900........ :grin:

[AstroTux]

James,

forgot to say, if you want to send me the binary I'm running 64-bit Linux Mint Mate.

cheers,

Alan

[JamesF]

Just emailed it

James

[mitchelln]

Nice to see someone doing Linux stuff! I'll have to give this a go

[JamesF]

I'm pleased to report that Alan dropped me an email earlier today to say that the binary I sent him works fine which is very pleasing to hear.  Just need to knuckle down and get a bit more done now.

Then I'll have to look into packaging stuff up in RPMs/.debs.  It's been quite some time since I built an RPM from scratch and I've never done a .deb.

James

[JamesF]

I almost forgot to mention...

I received a used QHY5 today, so I should be able to test that along with my QHY5L-II when the time comes.  There's not much else for Linux that supports the latter camera, so having one that I know works with other software will make life easier.

At the moment however I'm trying to get my head around the synchronisation between resolution changes and frame rate changes for V4L2 cameras.  Changing the resolution can alter the number of frame rates available.  For example, setting the SPC900 to 320x240 will allow it to run at 30fps whereas the maximum allowed at 640x480 is 15fps.  Debugging multithreaded applications is hard

James

[JamesF]

More progress this evening.  I have resolution and frame-rate changing working after a bit of a fight.  This means that the SPC900 appears to work nicely now for me.  I have one remaining niggle with the Lifecam where the V4L2 layer is giving an error when I try to change the exposure length and another issue with an old webcam that is also supported under V4L2 that shouldn't take long to tidy up.  Once I have those sorted I'll try running it with another couple of cameras and if no further errors present themselves then it looks like the actual capture side is sorted for V4L2 cameras.

Then I'll have to think about writing the data out onto disk.  Not sure how I'm going to go about that at the moment.  I might create another thread just for writing data to disk even if it is a bit hairy.

James

[NickK]

Now you're feeling how I felt ... lots of cameras to test support for

[Gina]

Great project James

I'm a Linux Lover but the way things are had to revert to Windoze when I took up astrophotography - there just wasn't enough software for Linux and what there was was crude compared with the Win stuff.  I felt it was hard enough to get sorted out anyway with the well supported Win apps without making yet another stick for my back.  Now I have a fair number of Linux only boxes lying around!  I started with an Asus netbook for my AP that was better specced than most of my Linux boxes but oh soooooo much slower running XP SP3.  I upgraded to a pretty high spec Win 7 64bit laptop for the obsy and that was certainly a big improvement but I still find I have to reboot quite often to get it to recognise all the connected devices.  Linux boxes just run and run as does OS X on my MacBook Pro.  With Ps being the bees-knees for astro image processing, I upgraded my desktop PC too to a high spec machine running Win 7 64 bit.  I find the Win 7 UI quite reasonable and it seems to have incorporated some Unix/Linux ideas.

Vi and vim "don't arf take me back"   I have programmed in all sorts of languages and don't find it difficult to change as they all use the same principles - just the syntax is different and I find I often have to look that up to refresh my memory.  It's now several decades since I did any heavyweight coding and now find many of the"little grey cells" have gone AWOL. Probably the biggest full blown software with user-friendly GUI, I've written was for the weather station using Python under Linux Mint.  I too went over to Mint when I considered Ubuntu had gone off course.  I still code a bit - mostly in the C++ style Arduino IDE.

I still run Mint on an older desktop I built up myself for some drawing apps.

Edited September 28, 2013 by Gina

[JamesF]

I guess my long-term goal Gina is to be able to do all the capture-side stuff on Linux if I can.  I can handle doing the processing on Windows if I must, but in my experience Linux (most flavours of UNIX, really) are so much more robust than Windows which makes them more suited to running unattended overnight or even over a period of weeks.  And I can't deny that it might be rather cool to be able to sit in the office working or stuck on a conference call, notice it's sunny, say, and be able to fire up the solar rig from my desk and do a bit of imaging without having to stop work

James

[Gina]

Yes, that would be great James   It would certainly be nice to be able to turn the power on to the mount and imaging rig and just run everything without having to reboot the darn computer.

[JamesF]

Well, I've (kind of) fixed the Lifecam errors I was getting.  So nice of the camera to lie about the default state of the auto-exposure control...

James

[Gina]

Well it's Microsoft, isn't it!  Nuff said.

[JamesF]

Well, I've spent a good few hours this evening trying to get the application to write AVI files and I'm still not there

Libraries for creating AVI files on linux are fairly thin on the ground -- there mostly seems to be ffmpeg, libav (an ffmpeg fork, I believe) and libavifile (which may use some ffmpeg code too).  They're utterly impenetrable and reliable documentation is scant where there is any at all.  In the end, libavifile seemed the least worst, but it's taken me most of the evening to find a codec it will actually allow me to use.  I did think about grabbing the Ut codec source, porting it to Linux and working out what I need by way of a wrapper around it to make it look like an avi, but that would mean that the file wouldn't play back under Linux

Hopefully I can get it finished tomorrow.  Then SER and FITS should be a doddle by comparison...

James

[cgarry]

With standard AVI libraries I could not figure out how to generate mono (DIB) AVI files that were not 3x the size the needed to be.  That is why I wrote my own class.  For the Ut Video codec (and MPEG-4) I just wrote a wrapper for ffmpeg and I am very pleased with how that worked.

Chris

[perfrej]

Hmmm... I booted my obsy computer in early August when I put the stuff back on the balcony. Hasn't been off or rebooted since, hasn't lost a session or part thereof, hasn't shown any hickups of any kind. I never did understand the "windows needs constant reboots" doctrine. The days of blue screens and reboots are over and have been since the introduction of Windows 7.

Apart from that, it would be interesting to put something resembling ACP together with the help of Qt. Crappy IDE but good thinking, cross-platform (if you chose compiler wisely).

Problem is device drivers...

/per

[JamesF]

With standard AVI libraries I could not figure out how to generate mono (DIB) AVI files that were not 3x the size the needed to be.  That is why I wrote my own class.  For the Ut Video codec (and MPEG-4) I just wrote a wrapper for ffmpeg and I am very pleased with how that worked.

Chris

Some seem to do it by just taking the mono data and creating a new RGB frame using the same pixel values for each channel.  Not exactly very efficient, as you say.

James

[AlexB67]

Hmmm... I booted my obsy computer in early August when I put the stuff back on the balcony. Hasn't been off or rebooted since, hasn't lost a session or part thereof, hasn't shown any hickups of any kind. I never did understand the "windows needs constant reboots" doctrine. The days of blue screens and reboots are over and have been since the introduction of Windows 7.

/per

I;d have to say I agree with you, this a bit of old adage in many cases, as far as I am concerned that has long gone for most things as far as the OS is concerned. I can't recall the last time I had a blue screen death or an OS  crash .... years. On the other side of the coin for heavy 3D stuff with DirectX and windows optimised drivers, when it comes to games, Linux has still a long way to go to compete with the Open source GPU drivers and speeds  that OpenGL  and also OpenCL implementations can provide in comparison ... in many cases anyway.

I do recall the old days however do when I used Linux in a more serious fashion,  on occasion rebooting Linux servers with an uptime of 300+ days, and the only reason they needed rebooting had nothing to do with the fact they had crashed, so in that sense I recall it be excellent, but IMHO windows 7 is a decent OS these days too