Astronomical data pixels are usually in units of counts^{194} or electrons or either one divided by seconds. To convert from the counts to electrons, you will need to know the instrument gain. In any case, they can be directly converted to energy or energy/time using the basic hardware (telescope, camera and filter) information (that is summarized in the zero point, and we will discuss below). We will continue the discussion assuming the pixels are in units of energy/time.
The brightness of an object is defined as its measured energy in units of time. If our detector pixels directly measured the energy from the astronomical object^{195}, then the brightness would be the total sum of pixel values (energy) associated to the object, divided by the exposure time. The flux of an object is defined in units of energy/time/collecting-area. For an astronomical target, the flux is therefore defined as its brightness divided by the area used to collect the light from the source; or the telescope aperture (for example, in units of \(cm^2\)). Knowing the flux (\(f\)) and distance to the object (\(r\)), we can define its luminosity: \(L=4{\pi}r^2f\).
Therefore, while flux and luminosity are intrinsic properties of the object, brightness depends on our detecting tools (hardware and software). In low-level observational astronomy data analysis, we are usually more concerned with measuring the brightness, because it is the thing we directly measure from the image pixels and create in catalogs. On the other hand, luminosity is used in higher-level analysis (after image contents are measured as catalogs to deduce physical interpretations, because high-level things like distance/redshift need to be calculated). At this stage, it is just important avoid confusion between luminosity and brightness because both have the same units of energy per seconds.
Images of astronomical objects span over a very large range of brightness: the Sun (as the brightest object) is roughly \(2.5^{60}=10^{24}\) times brighter than the fainter galaxies we can currently detect in the deepest images. Therefore discussing brightness directly will involve a large range of values which is inconvenient. So astronomers have chosen to use a logarithmic scale for the brightness of astronomical objects.
But the logarithm can only be usable with a dimensionless value that is always positive. Fortunately brightness is always positive (at least in theory^{196}). To remove the dimensions, we divide the brightness of the object (\(B\)) by a reference brightness (\(B_r\)). We then define a logarithmic scale as \(magnitude\) through the relation below. The \(-2.5\) factor in the definition of magnitudes is a legacy of the our ancient colleagues and in particular Hipparchus of Nicaea (190-120 BC).
$$m-m_r=-2.5\log_{10} \left( B \over B_r \right)$$
\(m\) is defined as the magnitude of the object and \(m_r\) is the pre-defined magnitude of the reference brightness. For estimating the error in measuring a magnitude, see Quantifying measurement limits.
A unique situation in the magnitude equation above occurs when the reference brightness is unity (\(B_r=1\)). This brightness will thus summarize all the hardware-specific parameters discussed above (like the conversion of pixel values to physical units) into one number. That reference magnitude is commonly known as the Zero point magnitude because when \(B=B_r=1\), the right side of the magnitude definition above will be zero. Using the zero point magnitude (\(Z\)), we can write the magnitude relation above in a more simpler format:
$$m = -2.5\log_{10}(B) + Z$$
Gnuastro has an installed script to estimate the zero point of any image, see Zero point estimation (it contains practical tutorials to help you get started fast). Having the zero point of an image, you can convert its pixel values to physical units like microJanskys (or \(\mu{}Jy\)). This enables direct pixel-based comparisons with images from other instruments^{197}. Jansky is a commonly used unit for measuring spectral flux density and one Jansky is equivalent to \(10^{-26} W/m^2/Hz\) (watts per square meter per hertz).
This conversion can be done with the fact that in the AB magnitude standard^{198}, \(3631Jy\) corresponds to the zero-th magnitude, therefore \(B\equiv3631\times10^{6}\mu{Jy}\) and \(m\equiv0\). We can therefore estimate the brightness (\(B_z\), in \(\mu{Jy}\)) corresponding to the image zero point (\(Z\)) using this equation:
$$m - Z = -2.5\log_{10}(B/B_z)$$ $$0 - Z = -2.5\log_{10}({3631\times10^{6}\over B_z})$$ $$B_z = 3631\times10^{\left(6 - {Z \over 2.5} \right)} \mu{Jy}$$
Because the image zero point corresponds to a pixel value of \(1\), the \(B_z\) value calculated above also corresponds to a pixel value of \(1\). Therefore you simply have to multiply your image by \(B_z\) to convert it to \(\mu{Jy}\). Do Not forget that this only applies when your zero point was also estimated in the AB magnitude system. On the command-line, you can estimate this value for a certain zero point with AWK, then multiply it to all the pixels in the image with Arithmetic. For example, let’s assume you are using an SDSS image with a zero point of 22.5:
bz=$(echo 22.5 | awk '{print 3631 * 10^(6-$1/2.5)}') astarithmetic sdss.fits $bz x --output=sdss-in-muJy.fits
But in Gnuastro, it gets even easier: Arithmetic has an operator called counts-to-jy
.
This will directly convert your image pixels (in units of counts) to Janskys though a provided AB Magnitude-based zero point like below.
See Arithmetic operators for more.
$ astarithmetic sdss.fits 22.5 counts-to-jy
Be careful with the exposure time: as described at the start of this section, we are assuming your data are in units of counts/sec. As a result, the counts you get from the command above, are only for one second of exposure! Please see the discussion below in “Magnitude to counts” for more. |
Until now, we had assumed that the data are in units of counts/sec. As a result, the equations given above (in the “Zero point” item to convert magnitudes to pixel counts), give the count level for the reference (1 second) exposure. But we rarely take 1 second exposures! It is therefore very important to take the exposure time into account in scenarios like simulating observations with varying exposure times (where you need to know how many counts the object of a certain magnitude will add to a certain image with a certain exposure time).
To clarify the concept, let’s define \(C\) as the counted electrons (which has a linear relation with the photon energy entering the CCD pixel). In this case, if an object of brightness \(B\) is observed for \(t\) seconds, it will accumulate \(C=B\times t\) counts^{199}. Therefore, the generic magnitude equation above can be written as: $$m = -2.5\log_{10}(B) + Z = -2.5\log_{10}(C/t) + Z$$ From this, we can derive \(C(t)\) in relation to \(C(1)\), or counts from a 1 second exposure, using this relation: $$C(t) = t\times10^{(m-Z)/2.5} = t\times C(1)$$ In other words, you should simply multiply the counts for one second with the number of observed seconds.
Another approach is to shift the time-dependence of the counts into the zero point (after all exposure time is also a hardware issue). Let’s derive the equation below: $$m = -2.5\log_{10}(C/t) + Z = -2.5\log_{10}(C) + 2.5\log_{10}(t) + Z$$ Therefore, defining an exposure-time-dependent zero point as \(Z(t)\), we can directly correlate a certain object’s magnitude with counts after an exposure of \(t\) seconds: $$m = -2.5\log_{10}(C) + Z(t) \quad\rm{where}\quad Z(t)=Z + 2.5\log_{10}(t)$$ This solution is useful in programs like MakeCatalog or MakeProfiles, when you cannot (or do not want to: because of the extra storage/speed costs) manipulate the values image (for example, divide it by the exposure time to use a counts/sec zero point).
Another important concept is the distribution of an object’s brightness over its area. For this, we define the surface brightness to be the magnitude of an object’s brightness divided by its solid angle over the celestial sphere (or coverage in the sky, commonly in units of arcsec\(^2\)). The solid angle is expressed in units of arcsec\(^2\) because astronomical targets are usually much smaller than one steradian. Recall that the steradian is the dimension-less SI unit of a solid angle and 1 steradian covers \(1/4\pi\) (almost \(8\%\)) of the full celestial sphere.
Surface brightness is therefore most commonly expressed in units of mag/arcsec\(^2\). For example, when the brightness is measured over an area of A arcsec\(^2\), then the surface brightness becomes:
$$S = -2.5\log_{10}(B/A) + Z = -2.5\log_{10}(B) + 2.5\log_{10}(A) + Z$$
In other words, the surface brightness (in units of mag/arcsec\(^2\)) is related to the object’s magnitude (\(m\)) and area (\(A\), in units of arcsec\(^2\)) through this equation:
$$S = m + 2.5\log_{10}(A)$$
A common mistake is to follow the mag/arcsec\(^2\) unit literally, and divide the object’s magnitude by its area. But this is wrong because magnitude is a logarithmic scale while area is linear. It is the brightness that should be divided by the solid angle because both have linear scales. The magnitude of that ratio is then defined to be the surface brightness.
One usual application of this is to convert an image’s pixel values to surface brightness, when you know its zero point. This can be done with the two simple commands below. First, we derive the pixel area (in arcsec\(^2\)) then we use Arithmetic to convert the pixels into surface brightness, see below for the details.
$ zeropoint=22.5 $ pixarea=$(astfits image.fits --pixelareaarcsec2) $ astarithmetic image.fits $zeropoint $pixarea counts-to-sb \ --output=image-sb.fits
See Reverse polish notation for more on Arithmetic’s notation and Arithmetic operators for a description of each operator. And see FITS images in a publication for a fully working tutorial on how to optimally convert a FITS image to a PDF image for usage in a publication using the surface brightness conversion shown above.
Do Not warp or convolve magnitude or surface brightness images: Warping an image involves calculating new pixel values (of the new pixel grid) from the old pixel values. Convolution is also a process of finding the weighted mean of pixel values. During these processes, many arithmetic operations are done on the original pixel values, for example, addition or multiplication. However, \(log_{10}(a+b)\ne log_{10}(a)+log_{10}(b)\). Therefore after calculating a magnitude or surface brightness image, do not apply any such operations on it! If you need to warp or convolve the image, do it before the conversion. |
Counts are also known as analog to digital units (ADU).
In practice, the measured pixels don’t just count the astronomical object’s energy: imaging detectors insert a certain bias level before the exposure, they amplify the photo-electrons, there are optical artifacts like flat-fielding, and finally, there is the background light.
In practice, for very faint objects, if the background brightness is over-subtracted, we may end up with a negative “brightness” or sum of pixels in a real object.
Comparing data from different instruments assumes instrument and observation signatures are properly corrected, things like the flat-field or the Sky absorption. It is also valid for pixel values, assuming that factors that can change the morphology (like the Point spread function) are the same.
https://en.wikipedia.org/wiki/AB_magnitude
Recall that counts another name for ADUs, which already includes the CCD gain.
JavaScript license information
GNU Astronomy Utilities 0.20 manual, April 2023.