Jump to content

Banner.jpg.b89429c566825f6ab32bcafbada449c9.jpg

Help with pixel count and image size relations


keithc

Recommended Posts

Hi, apologies if this is a dumb question but, I'm thinking of upgrading from a DSLR (Nikon D5200 unmodded) to a mono CCD and filters. I'm leaning towards the Atik 414EX as it gets great reviews. However, although I'm not new to photography I am relatively new to astrophotography. The sensor in my D5200 is 6000 x 4000 pixels and, at the standard print resolution of 300 ppi, gives a print size of 20 x 13.33 inches. I recently imaged M31 (attached) stacked from 22 Lights. This produced a TIFF file that was a whopping 168 x 112 inches at 72 ppi. Reducing this to 300 ppi in PS gave a print size of 40 x 26 inches. Now the Atik 414EX is 1392 x 1040 pixels so at 300 ppi a single frame would produce a print size of 4.64 x 3.47 inches. what I would like to understand is the relationship between the number of stacked images and the final image size, or am I just misunderstanding this whole thing? Are there any online tutorials that would explain this to me as it relates to mono CCD imaging using LRGB filters?

M31.jpg

Link to comment
Share on other sites

No relationship what so ever (well there is, but it is consequence of other things, rather than number of stacked frames).

Here is break down of what you need to know:

1. Pixel count in width and height of sensor will tell you size of image on a computer, but will also tell you print size depending on selected DPI - this part, I'm certain, you understand well. This holds unless you use binning or drizzle or other processing techniques that increase or decrease pixel count of resulting stack (advanced stuff so don't worry about this if you don't know about it yet - these are special cases of data manipulation)

2. Number of stacked images has no relation to pixel count (or width and height of resulting stack in pixels). Each sub in stack is aligned, so there is almost exact correspondence between each individual pixel in all stacks - they end up in pretty much the same place. If anything stack of subs will have less total pixels than pixel count of sensor - but not because of stacking process, rather because frame shifts between subs (tracking / guiding error, or deliberate dither), or is rotated (multiple session or not perfect polar align) and in the end you end up with cropping away edges that did not stack perfectly (not all subs have pixels in that particular place after align).

I'll try dumb analogy here - you have a bank account - multiple deposits to this account increase total balance (signal in the image), but don't create multiple accounts for you (you will not end up with more pixels than you started with).

3. There is a way that you can make "poster sized" images (this relates to print size - or large pixel count image), even with very small sensor (in terms of pixel count) - Mosaics. In this process you image multiple panels in the same way you would image single panel target (multiple subs, calibration, stacking, ....) but you take images of panels that sit next to each other in the sky. When you complete each panel, you simply "stitch them together" to produce larger image - this process increases pixel count (adds all pixels from each panel) but does not do what stacking does - it does not improve signal in panels further. It's like taking any two images and putting them next to each other (either horizontally, or vertically) - you end up with "larger" image (more pixels). Of course there are technical details like: some parts of panels need to overlap (close to edge) so you can align them properly - meaning total resulting pixel count will be less than sum of individual pixel counts. You need to combine them prior to stretching and post processing, and you need to equalize signal strengths and background levels - so you get seamless transition - but all of that should be handled in software.

Link to comment
Share on other sites

I would forget print size entirely and concentrate on primary values. These are:

1) Chip size in mm, horizontally and vertically. Your telescope will project an image onto whatever chip is put under it. The size of the chip determines how much of that projected image will be recorded. The size of the telescope's corrected circle will decide how much of what's recorded will be worth keeping. So the scope's corrected circle needs to be at least as large as the chip's diagonal, both in mm. Illumination across the chip may (will) be uneven but flats should correct this.

2) Pixel size. (Not pixel count.) The pixel size and the focal length define the image scale of the system in arcseconds per pixel. If you go below about 0.9 arcsecs per pixel you really are going to need stable seeing and an excellent and well guided mount. If you go above about 3.5 arcseconds per pixel you are going to get blocky stars and a pixelated image when seen at full size. The numerical values I'm giving are the ones I've found to apply at my site. They may well not agree with the findings of others at other sites but they are going to give you a ballpark figure.

There are key differences between normal and astronomical photography. It is unlikely that you would have pixels which were too small in normal photography, especially in bright light. In AP, if they are smaller than the seeing or guiding will support, they simply don't get enough light and their theoretical resolution cannot be realized. The key thing in AP is to get enough light onto each pixel so they should be as big as possible consistent with delivering the resolution which the seeing, the optics and the guiding will allow.

Olly

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • 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.