What Makes A Good Planetary Camera?

[billhinge]

I was just looking at a uk website this afternoon http://www.smallpoecamera.co.uk/ (no affiliation to them) and I was wondering what makes a good planetary camera or dslr

I know people discuss individual cameras but was interested in specs, i.e. if you could pick what feature you wanted, what would you choose and why (reason for asking - in case I see something interesting

ie

global/revolving shutter - does it matter for planets

usb 2.0/firewire/GiGEthernet

chip size

pixel size

raw/cooked format - is a large raw format file useable with registax etc?

any thoughts appreciated

[badgers]

I got the impression from the planetary imagers that Frames per second is one of the key factors and more important than resolution and many other factors.

[NickK]

* Low noise

* high shutter speed, in my view an electronic shutter is more favourable for planetary than a mechanical

* high download (this with shutter speed gives frames per second)

* good well-depth (gives a good dynamic range)

To me pixel size is more related to well-depth. A small pixel is likely to give a smaller dynamic range before it's saturated. However I don't think this is a problem for the experienced imager.

The aperture size and focal length will then give you more resolution still... that requires a good mount (although a high shutter speed helps reduce issues with this).

[riklaunim]

I was just looking at a uk website this afternoon http://www.smallpoecamera.co.uk/ (no affiliation to them) and I was wondering what makes a good planetary camera or dslr

Those are new TIS industry GigE cameras. Similar to the USB2 sold officially as astro cameras. Some of those GigE could be interesting for lunar (ICX445) and planetary imaging - if they don't show any artifacts at such framerates.

global/revolving shutter - does it matter for planets

Progressive scan CCD (most Sony CCDs) or Global shuttered CMOS are ok. Rolling shuttered CMOS may be not so good. Interlaced CCD shutter - bad (some guiders like Lodestar/Brightstar). Mechanical shutter is to slow, so KAF sensors aren't used.

usb 2.0/firewire/GiGEthernet

For planetary USB2 is ok. For lunar/solar with bigger sensors faster connections are handy (GigE, Firewire 800 and USB3 which is still rare).

chip size

pixel size

For planetary it may be small (and cheap). For lunar/solar bit bigger are used (but usually smaller than in average DS camera and much smaller in DSLR or better DS cameras). Pixel size - avoid very small pixels.

raw/cooked format - is a large raw format file useable with registax etc?

90% are lossless AVIs (Y800 and alike codecs). This is supported by Registax, Castrator, Autostakkert and so on. FITS, TIFFs, DSLR RAW are rarely used.

In general a planetary camera must provide high framerate (let say at least 30 FPS; 8-bit data), low read noise under high gain and no artifacts. It also must be supported by a sane application (FireCapture, IC.Capture.AS... especially mono cameras). It must also have a sensitive sensor to allow even more efficient imaging.

All high end Solar System cameras use Sony CCDs (ICX618, 445, and even 674/694). In some entry level cameras we have Aptina/Micron CMOS sensors (high read noise, mostly rolling shutter), and in some plausible future cameras we may see some specialized CMOS sensors - big CMOSIS sensors for lunar/solar (1" diagonal... almost like in Atik 4000, but USB3 will give 90 FPS of a 2048 x 2048 frame), or e2v ruby/sapphire line CMOS sensors (semi sized diagonal for any Solar System object, either global shuttered version with good performance or rolling shutter with insane sensitivity and low noise)... and the prices are going down. Cams like DMK31-41 are getting to expensive and older every day.

[billhinge]

Thanks

Could I ask a question?

Is the aversion to small pixel size down to smaller pixels are likely to be noisier?

"In general a planetary camera must provide high framerate (let say at least 30 FPS; 8-bit data), low read noise under high gain and no artifacts. It also must be supported by a sane application (FireCapture, IC.Capture.AS... especially mono cameras). It must also have a sensitive sensor to allow even more efficient imaging"

So this means 30FPS x 8bit x 3 channels x horizontal x vertical size bits per second and the connection should be able to sustain this for a raw file ? (less if compressed)

thanks

Steve

[pete_l]

So this means 30FPS x 8bit x 3 channels x horizontal x vertical size bits per second and the connection should be able to sustain this for a raw file ? (less if compressed)

Almost all OSC cameras will have a Bayer matrix of 4 pixels (1 * Red, 2 * Green, 1 * Blue). So for the sake or argument if your camera has 640*480 px, the best to hope for is a raw download of that many px per frame - rather than have the camera de-Bayer the image and "magically" produce 3 times the data to squeeze down the USB wire.

If you do that, you'll be able to increase the frame rate and still use a USB 2.0 connection to the camera providing you have a disk or SSD that's fast enough to catch all the data being thrown at it.

[billhinge]

Thanks Pete

I was thinking that was a lot of data, my confusion was from reading an older post were someone said something similar and no one corrected it

so are you saying in this example we are only talking about 640 x 480 x 30 x 8 bits of data ? i.e. 73.7Mbit/sec

[pete_l]

Thanks Pete

I was thinking that was a lot of data, my confusion was from reading an older post were someone said something similar and no one corrected it

so are you saying in this example we are only talking about 640 x 480 x 30 x 8 bits of data ? i.e. 73.7Mbit/sec

Sounds about right (I left my slide-rule at work ), wassat? about 9 MByte/sec. Quite do-able for USB 2.0 or gigabit ethernet

Now, if the camera produced 16 bits per pixel AND ran at 60 FPS, then things start to get interesting at 36 MByte/sec

However, if the camera was de-Bayering then yes, you would get 640 * 480 * 3 * 2 (16 bit data) * 60 (FPS) which is slightly over the top for ethernet and not something I've ever seen across a single USB 2 connection.

[billhinge]

Cheers Pete

[riklaunim]

Is the aversion to small pixel size down to smaller pixels are likely to be noisier?

It's harder to make small pixel sensitive and also they will have lower well depth, which may limit dynamic range. Probably some high end backside illuminated CMOS with small pixels would work nicely, but those aren't common yet.

[Ronnie67]

So which ccd would you recommend which is not over expensive

[riklaunim]

So which ccd would you recommend which is not over expensive

What's your budget?

In mono starting from most expensive (that are good):

- DMK21AU618 (best planetary) (+/- iNova PLA-Mx)

- Point Grey Chameleon (nearly best lunar/solar, good planetary)

- iNova PLA-M (ICX098, cheapest, but the sensor is older and less sensitive, like old DMK21 but better priced and no artifacts)

In color starting from most expensive:

- DBK21AU618 (but some users have patterns problems?)

- Point Grey Chameleon color (well... for lunar/solar color cameras are less useful. But they do work)

- iNova PLA-C+ (ICX098, cheapest, but the sensor is older and less sensitive)

Other options:

- IDS UI-1240LE-M / UI-1245LE-M mono - bigger diagonal, good CMOS, 370 EUR base price. Good for lunar/solar (bigger diagonal), for planets it works too (fast framerate with small subframe) but you are limited to IDS capture software (so you have to change exposure/gain settings every time you change a filter etc.).

[beamish]

you could do with looking at this if it's not out of your budget- get free guiding with it too

http://stargazerslounge.com/classifieds/item/9-i-nova-pla-mx-ccd-lunarplanetaryguide-camera-sale-pending/

Ooops sorry , just spotted the "sale Pending" -hey perhaps it's yourself !!