PlanetaryImager - Windows, Linux, OSX planetary capture software

[GuLinux]

Hello, that's very nice to hear

Yes, 0.7 is getting very close to release... I'd like to stabilize QHY driver and packaging before that, but apart from that, it should be quite stable for daily use.

v0.8 doesn't have much new at the moment... huge refactorings, and lots of instability, so leave it alone for now  But there's a lot planned, I will probably announce it in here when an usable beta will be available.

 

As for the speed... I really don't know, I might further optimise the capture routines, but I'm not sure if you've hit some kind of capping somewhere else in the stack (kernel, libusb, etc).

As I probably already mentioned, I had a few interesting issues with my Dell laptop, it really couldn't handle the 60FPS advertised by ASI, some kind of incompatibility, but then it got much better, without any changes to PlanetaryImager itself.

 

Also, I think that the advertised FPS by ASI doesn't really add up... If the camera works at 174 FPS in 8bit mode, then in 16bit it should be exactly a half. You might say, since it's actually 12bits, they might save some space (and speed) by  not padding the bytes, and transferring exactly 12 bits instead of 16 padded with 0, but that's not what it seems, with my cameras (I have 2 ASI) the 12/14 bit speed is always exactly a half than the 8 bit speed.

Surely, it needs investigating further... maybe we should both contact ASI for clarifications.

Cheers,

Marco

[rpineau]

Hi Marco.

I agree with you about the announced speed... marketing fluff ?... that being said the AD converts 8 or 12 bit. in 12 bit mode it then expands it to 16 bits (left shift by 4 bits and nothing else so this takes no time). so the ratio of 12 to 8 gives almost the 128 FPS they announce for 12 bits...  or it is indeed exactly half the speed because the 12 bit AD conversion does take twice as much time independently of the rest of the capture. Not sure either but I've seen the same thing in other apps, not just yours so I'm fairly sure it's not something in the code. It might very well be in their SDK and there is not a lot you can do about this.

But I'm already pleased with a 130FPS or 66FPS.

Thanks for the great work.

Regards, Rodolphe

[GuLinux]

14 hours ago, rpineau said:

Hi Marco.

I agree with you about the announced speed... marketing fluff ?... that being said the AD converts 8 or 12 bit. in 12 bit mode it then expands it to 16 bits (left shift by 4 bits and nothing else so this takes no time). so the ratio of 12 to 8 gives almost the 128 FPS they announce for 12 bits...  or it is indeed exactly half the speed because the 12 bit AD conversion does take twice as much time independently of the rest of the capture.

no, I'm not saying it's the 16bit conversion, but the USB transfer speed. if you have to transfer 16bits instead of 8, (so twice the data) then it takes exactly double the time. 

I think what they're advertising is just the specification of the sensor itself (which of course is a third party component). but after that, your data have to go through the USB port, using a zwo defined protocol, which can be another bottleneck. Another hint that this is the case is given by the advertised 10 bit: there is no such thing, it's just downscaled to 8 bits as well. 

14 hours ago, rpineau said:

Not sure either but I've seen the same thing in other apps, not just yours so I'm fairly sure it's not something in the code. It might very well be in their SDK and there is not a lot you can do about this.

But I'm already pleased with a 130FPS or 66FPS.

Thanks for the great work.

Regards, Rodolphe

that's the most important part :-) afterall, in real life, you'd have to use an extremely low exposure to reach 170 fps :-)

[rpineau]

Hi Marco.

Yea , I forgot about the actual wire protocol. You're right .. 16 bit vs 8 in the usb data packet, even if they do usb bulk transfer async it's still twice as much data so half the speed makes sense.

I plan on running more test on the Sun this weekend so I'm capturing at full resolution.

I did some ROI test on my dsck and of course the FPS goes a lot higher  which will be good for planetary

Regards, Rodolphe

 

[GuLinux]

Hi everyone,

Just a quick notice about 0.7.0 release: http://blog.gulinux.net/en/planetary-imager/downloads

Unfortunately there are no great news since the latest 0.7-beta3 version, didn't really have a lot of time lately, but a lot of bugs were fixed in the meantime, including some more testing on the OSX and Windows version.

QHY support has been temporarily dropped, since their SDK is being updated in the meantime.

Lots of interesting stuff will now be implemented for 0.8, so keep tuned!