A “value-added mosaic” is a FITS-format image file containing a scan of a single photographic plate. The word “mosaic” here may be somewhat confusing in the context of standard astronomical usage: it does not refer to a combination of multiple separate sky images. In DASCH, it refers to the fact that each plate scan consists of numerous 4k×4k exposures (“tiles”) that must be combined to generate a single image that captures the entire plate. For most use cases, there will never be a need to examine the individual tiles.

The “value-added” files documented on this page are generated by the daschlab analysis package, which combines several low-level DASCH data products to create mosaic FITS files with extensive metadata and standardized headers. The “base” mosaics that are directly delivered by the DASCH web APIs do not include several kinds of metadata, most importantly WCS solutions, and should generally be avoided.

Obtaining the Files

In daschlab, obtain a value-added mosaic file using the Session.mosaic() method. This will download the base mosaic and save it to disk, and then combine that file with other metadata to generate the value-added mosaic. The value added-mosaics are stored in the mosaics subdirectory of your session’s data storage area.

If you truly want to use full-plate mosaics without using daschlab, you should study the code in the daschlab.mosaics Python module to understand the transformations that are needed to convert the base files (provided by the POST /dasch/dr7/mosaic_package web API endpoint) to the final value-added products.

Structure

Value-added mosaic files contain the following header data units (HDUs):

Excluding WCS headers, the headers in the primary HDU are:

WCS Headers

If any astrometric solutions were derived for the plate, its primary HDU will contain (mostly) standard WCS headers.

Some DASCH plates were exposed multiple times, and the DASCH pipeline can determine multiple astrometric solutions for such plates. In these cases, the primary HDU will contain multiple sets of WCS solutions using the FITS-WCS standard’s support for “alternative axis descriptions”. The first discovered solution (solution number 0) is recorded with keywords CRPIX1, CRVAL2, etc.; the second solution is recorded with keywords CRPIX1A, CRVAL2A, etc.; the third with CRPIX1B, CRVAL2B; and so on. The ordering of the solutions has no special significance, and in particular may not map cleanly to the chronological sequence of the plate’s logged exposures.

There may be WCS solutions that cannot be associated to logged exposures, if the logged information is incomplete or incorrect. Conversely, there may be logged exposures without corresponding WCS solutions. The EXPOSURS HDU gives detailed information about what the pipeline was able to determine.

The DASCH WCS solutions use the special RA---TPV and DEC--TPV coordinate types, which signal a gnomonic (TAN) projection with distortion terms encoded in PVi_j header keywords. Astropy recognizes this syntax and will automatically apply the distortion terms. It is essential to apply the distortions, because DASCH plates are so large on the sky that astrometric errors at the plate edges become highly significant if they are not applied.

Detailed Header Keyword Information (Alphabetical)

Primary HDU: D_ASRID

• Synopsis: Hexadecimal ID of the DASCH astrometry result
• Units/type: hexadecimal string

If present, this is a string of hexadecimal text identifying the specific DASCH astrometric pipeline data product that provided the astrometric solution for this plate. In principle, subsequent reprocessing of the same plate can yield a different (hopefully better) result.

In DASCH DR7, there are no APIs that make use of this value, so it is purely informative. It can be used to recover the log files associated with the mosaic processing job.

If missing, the pipeline was unable to determine any astrometric solutions for this plate.

Primary HDU: D_BINLEV

• Synopsis: Binning level of this mosaic
• Units/type: integer, 1 or 16

The level of pixel binning applied to this mosaic. A value of 1 indicates a full-resolution mosaic; 16 indicates a derived 16×16 binned mosaic.

Primary HDU: D_ERASED

• Synopsis: Whether the markings were erased for DASCH scanning
• Units/type: boolean (integer 0 or 1)

If true, this indicates that DASCH records indicate that this plate used to have handwritten markings on it, and that they were erased prior to the plate being scanned. If that is the case, the photographs of the plate are the only documentation of what was written on the plate. The vast majority of plates with markings on them were erased, with the exception of A-series plates scanned after 2022.

It is possible that database logging errors may result in this field having an incorrect value.

Primary HDU: D_MARKED

• Synopsis: Whether this plate had handwritten markings
• Units/type: boolean (integer 0 or 1)

If true, this indicates that DASCH records indicate that this plate originally had handwritten markings on it. The vast majority of plates with markings had them erased prior to DASCH scanning, with the exception of A-series plates scanned after 2022. The header D_ERASED records whether the database indicates that erasure occurred.

It is possible that database logging errors may result in this field having an incorrect value.

Primary HDU: D_MCTAP

• Synopsis: Median colorterm in the APASS refcat
• Units/type: float

This field is exactly equivalent to median_colorterm_apass in an exposure list table. Read that documentation for details.

Primary HDU: D_MCTAT

• Synopsis: Median colorterm in the ATLAS refcat
• Units/type: float

This field is exactly equivalent to median_colorterm_atlas in an exposure list table. Read that documentation for details.

Primary HDU: D_MDEXP

• Synopsis: Sequence number of the exposure used for DATE-OBS and/or XPOSURE
• Units/type: nonnegative integer

The FITS standard defines only a single keyword, DATE-OBS, to record the observation date associated with an image; likewise for XPOSURE, its exposure duration. This presents a problem for DASCH because some plates were exposed multiple times, and each exposure has its own associated time and duration.

The approach taken in these files is to choose one logged exposure to provide representative values for these headers. When plates were exposed multiple times, those exposures usually occurred rapidly in sequence, so none of the values are too different. The EXPOSURS binary table HDU gives detailed information if more precise analysis is needed.

This field, if present, gives the expnum value of the exposure that was chosen to populate the metadata fields.

Primary HDU: D_MDSOL

• Synopsis: WCS solution number of the exposure used for DATE-OBS and/or XPOSURE
• Units/type: nonnegative integer

See D_MDEXP. If present, this header is analogous, but specifies the solnum of the exposure used to populate the metadata. It may be missing if the pipeline was unable to identify a WCS solution corresponding to the exposure with the best metadata.

Primary HDU: D_MOSNUM

• Synopsis: Sequence number of this mosaic file
• Units/type: nonnegative integer

This field is exactly equivalent to mosnum in an exposure list table. Read that documentation for details.

Primary HDU: D_MOSRID

• Synopsis: Hexadecimal ID of the DASCH mosaicdata result
• Units/type: hexadecimal string

This is a string of hexadecimal text identifying the specific DASCH mosaicking pipeline data product that created the mosaic image contained in this file. In principle, subsequent reprocessing of the same raw tile data could yield a different result.

In DASCH DR7, there are no APIs that make use of this value, so it is purely informative. It can be used to recover the log files associated with the mosaic processing job.

Primary HDU: D_NCNAMS

• Synopsis: Number of names identified in the plate’s curator comment
• Units/type: nonnegative integer

This is the number of astronomer names that the Starglass named entity recognition algorithm was able to extract from the Plate Stacks Curator’s comment associated with this plate. There will be one row in the PEOPLE table for each such identification.

Machine learning processing was needed to identify these names because the curator’s comment is freeform text, and names appear in many forms, and there are a lot of comments. As with all machine learning tasks, there was an error rate associated with the processing, so there may be both false negatives and false positives in the identifications.

Primary HDU: D_NENS

• Synopsis: Number of logged exposures without WCS solutions
• Units/type: nonnegative integer

This counts how many exposures were recovered from DASCH’s analysis of the observing logbooks, but that the pipeline couldn’t identify with a WCS astrometric solution. For each of these, there should be a row in the EXPOSURS table with a valid expnum but invalid solnum.

Primary HDU: D_NEXP

• Synopsis: Number of logged exposures of this plate
• Units/type: nonnegative integer

This counts how many exposures were recovered from DASCH’s analysis of the observing logbooks associated with this plate. There will be at least this many rows in the EXPOSURS table, with valid expnum values ranging from 0 to D_NEXP - 1. However, the ordering rows in the table will be arbitrary.

Primary HDU: D_NJPHOT

• Synopsis: Number of DASCH photographs of the plate jacket
• Units/type: nonnegative integer

This counts how many DASCH plate jacket photographs are associated with this plate. There will be a row in the PHOTOS table with a kind of "jacket" for each such photograph. Most plates have at most one jacket photograph, but in some cases different corners of the jacket were photographed separately.

Primary HDU: D_NMDAP

• Synopsis: Number of solutions with spatial magnitude-dependent calibration, in the APASS refcat
• Units/type: nonnegative integer

This field is exactly equivalent to n_magdep_apass in an exposure list table. Read that documentation for details.

Primary HDU: D_NMDAT

• Synopsis: Number of solutions with spatial magnitude-dependent calibration, in the ATLAS refcat
• Units/type: nonnegative integer

This field is exactly equivalent to n_magdep_atlas in an exposure list table. Read that documentation for details.

Primary HDU: D_NMNTNS

• Synopsis: Number of plate mentions identified in PHaEDRA notebooks
• Units/type: nonnegative integer

This counts how many mentions of this plate were identified by citizen-science volunteers in the digitized PHaEDRA notebooks. There will be one row in the PEOPLE table for each such mention.

Primary HDU: D_NPPHOT

• Synopsis: Number of DASCH photographs of the plate
• Units/type: nonnegative integer

This counts how many DASCH plate photographs are associated with this plate. There will be a row in the PHOTOS table with a kind of "plate" for each such photograph. Most plates have at most one plate photograph, but in some cases different regions of the plate were photographed separately.

If a plate has a true value for D_ERASED, these photographs provide the only record of the handwritten markings written on the plate before erasure. Besides that, the DASCH scan data should be preferred for all quantitative analysis of the plate image.

Primary HDU: D_NSAP

• Synopsis: Number of photometric solutions in the APASS refcat
• Units/type: nonnegative integer

This field is exactly equivalent to n_solutions_apass in an exposure list table. Read that documentation for details.

Primary HDU: D_NSAT

• Synopsis: Number of photometric solutions in the ATLAS refcat
• Units/type: nonnegative integer

This field is exactly equivalent to n_solutions_atlas in an exposure list table. Read that documentation for details.

Primary HDU: D_NSNE

• Synopsis: Number of WCS solutions not associated with exposures
• Units/type: nonnegative integer

This counts how many astrometric solutions were identified by the DASCH pipeline that couldn’t be identified with exposures recovered from DASCH’s analysis of the observing logbooks. For each of these, there should be a row in the EXPOSURS table with a valid solnum but invalid expnum.

Primary HDU: D_NSOL

• Synopsis: Number of WCS solutions for this plate
• Units/type: nonnegative integer

This counts the number of astrometric solutions that could be identified by the DASCH pipeline. For each of these, the primary HDU will contain a set of WCS headers stored using the standard’s support for “alternative axis descriptions”. See the WCS Headers section above for details.

For each solution there will also be a row in the EXPOSURS table. It is guaranteed that the first row in that table will correspond to the first WCS solution (solnum = 0), the second row to the next solution (solnum = 1), and so on, up until D_NSOL - 1.

There may be zero astrometric solutions.

Primary HDU: D_OBSACC

• Synopsis: Estimated uncertainty on DATE-OBS
• Units/type: days

If present, this is the value of u_date in EXPOSURS corresponding to the exposure selected to fill the DATE-OBS field (expnum = D_MDEXP). See the u_date entry for more information.

Primary HDU: D_OBSSRC

• Synopsis: Source of DATE-OBS information
• Units/type: string

If present, this is the value of date_src in EXPOSURS corresponding to the exposure selected to fill the DATE-OBS field (expnum = D_MDEXP). See the date_src entry for more information.

Primary HDU: D_ORGMD5

• Synopsis: MD5 of the uncompressed base mosaic file
• Units/type: hexadecimal string

This records the MD5 digest of the base mosaic file from which this value-added mosaic was derived.

Importantly, this is the MD5 of the uncompressed base file originally stored on the DASCH data processing servers. The DASCH data products are fpack-ed versions of those files, and so the base mosaic file stored in the base_mosaics directory (or returned by the DASCH web APIs) will not have an MD5 that matches the value given in this header. To verify the match, you must first funpack that file using the -C argument, which prevents funpack from adding a checksum header not present in the original.

Primary HDU: D_ORGSZ

• Synopsis: Size of the uncompressed base mosaic file
• Units/type: bytes

This records the size in bytes of the uncompressed base mosaic file from which this value-added mosaic was derived. The base mosaics distributed by the DASCH web APIs are compressed, and must be decompressed before you can verify this value. See D_ORGMD5 for details.

Primary HDU: D_PCLASS

• Synopsis: The logged plate class category
• Units/type: string

If present, this field is exactly equivalent to class in an exposure list table. Read that documentation for details. Be aware that DASCH plate class metadata are often missing or inaccurate.

Primary HDU: D_PLATE

• Synopsis: The DASCH/Starglass plate ID
• Units/type: string

The unique identifier of this plate. It has the form {series}{number}, where the plate number is padded with zeros to be five digits long.

Primary HDU: D_PLNUM

• Synopsis: This plate’s number within its series
• Units/type: integer

This field is exactly equivalent to platenum in an exposure list table.

Primary HDU: D_RIDAP

• Synopsis: Hexadecimal ID of the DASCH photcal result for the APASS refcat
• Units/type: hexadecimal string

If present, this field is exactly equivalent to result_id_apass in an exposure list table. Read that documentation for details.

Primary HDU: D_RIDAT

• Synopsis: Hexadecimal ID of the DASCH photcal result for the ATLAS refcat
• Units/type: hexadecimal string

If present, this field is exactly equivalent to result_id_atlas in an exposure list table. Read that documentation for details.

Primary HDU: D_SCNNUM

• Synopsis: Sequence number of this scan
• Units/type: nonnegative integer

This field is exactly equivalent to scannum in an exposure list table. Read that documentation for details.

Primary HDU: D_SERIES

• Synopsis: The plate series to which this plate belongs
• Units/type: string

This field is exactly equivalent to series in an exposure list table.

Primary HDU: DASCHCIT

• Synopsis: Information about citing DASCH
• Units/type: string

This is freeform text about how to cite DASCH. It's placed at the top of the FITS file to try to nudge people in the right direction.

Primary HDU: DASCHLAB

• Synopsis: Version of daschlab that made this file
• Units/type: string

The version number of daschlab that made this file. Files created by later versions should be preferred.

Primary HDU: DASCHVAM

• Synopsis: General DASCH marker; data release version
• Units/type: string

The contents of this header will be "DR7". It’s placed at the top of the FITS file to indicate the origin of the data.

Primary HDU: DATE-MOS

• Synopsis: Date that the base mosaic was created
• Units/type: FITS time

The date that the underlying base mosaic file was created. This shouldn’t be important to any analysis.

Primary HDU: DATE-OBS

• Synopsis: Representative midpoint date of the observation
• Units/type: FITS time

If present, this is the geocentric midpoint UTC date-time of an exposure associated with this plate. If the plate was exposed multiple times, this number is not necessarily precisely meaningful. However, multiple exposures generally occurred in rapid succession, so it will be approximately accurate. See the discussion in the D_MDEXP entry. The EXPOSURS binary table HDU provides comprehensive information about the plate’s exposures, to the extent that it is available. Some plates have no logged exposure information.

Primary HDU: DATE-SCN

• Synopsis: Date that the plate was scanned
• Units/type: FITS time

The date that this plate was scanned. More precisely, it is the date of the scan whose data went into creating this mosaic; some plates were scanned more than once.

Primary HDU: HEIGHT

• Synopsis: Altitude of the observatory
• Units/type: meters

The altitude of the observatory at which this plate was exposed, according to DASCH’s records. This is the same information as returned by the GET /locations web API, and subject to the same limitations. The quality of DASCH’s values for these locations is not well-assessed; prefer data from a better-maintained source, such as Astropy’s site list.

Primary HDU: LATITUDE

• Synopsis: Latitude of the observatory
• Units/type: degrees

The latitude of the observatory at which this plate was exposed, according to DASCH’s records. This is the same information as returned by the GET /locations web API, and subject to the same limitations. The quality of DASCH’s values for these locations is not well-assessed; prefer data from a better-maintained source, such as Astropy’s site list.

Primary HDU: LONGITUD

• Synopsis: East longitude of the observatory
• Units/type: degrees

The longitude (east positive) of the observatory at which this plate was exposed, according to DASCH’s records. This is the same information as returned by the GET /locations web API, and subject to the same limitations. The quality of DASCH’s values for these locations is not well-assessed; prefer data from a better-maintained source, such as Astropy’s site list.

Primary HDU: MJD-MOS

• Synopsis: MJD corresponding to DATE-MOS
• Units/type: float

See DATE-MOS.

Primary HDU: MJD-OBS

• Synopsis: MJD corresponding to DATE-OBS
• Units/type: float

See DATE-OBS.

Primary HDU: MJD-SCN

• Synopsis: MJD corresponding to DATE-SCN
• Units/type: float

See DATE-SCN.

Primary HDU: S_OPER

• Synopsis: Name of the scanner operator
• Units/type: string

This is the name of the person operating the scanner when the plate was scanned.

Primary HDU: SITE

• Synopsis: Name of the observatory
• Units/type: string

Human-readable name of the observatory where this plate was exposed.

Primary HDU: TELESCOP

• Synopsis: Name of the telesope
• Units/type: string

Human-readable name of the telescope used to expose this plate.

Primary HDU: XPOSURE

• Synopsis: Duration of the selected exposure
• Units/type: days

If present, this is the duration of an exposure associated with this plate. If the plate was exposed multiple times, this number gives only one of several possible values. See the discussion in the D_MDEXP entry. The EXPOSURS binary table HDU provides comprehensive information about the plate’s exposures, to the extent that it is available. Some plates have no logged exposure information.

Detailed Column Information (Alphabetical)

EXPOSURS.ctr_dec

• Synopsis: Declination of the exposure pointing center
• Units/type: degrees

This may not be known. See ctr_src.

EXPOSURS.ctr_ra

• Synopsis: Right ascension of the exposure pointing center
• Units/type: degrees

This may not be known. See ctr_src.

EXPOSURS.ctr_src

• Synopsis: Source of the exposure pointing center information
• Units/type: string

This field is similar to wcssource in an exposure list table. It describes the origin of the positional information for this exposure record. Allowed values are "" (the empty string), "Catalog", "Logbook", or "imWCS".

An empty value indicates that there is no positional information for this exposure. Sometimes this happens.

The value "Catalog" indicates that the positional information comes from a plate stacks card catalog. Due to rounding and transcription errors, this information may not be very accurate.

The value "Logbook" indicates that the positional information comes from a transcribed observing log. Due to rounding and transcription errors, this information may not be very accurate, although it may be somewhat better than "Catalog".

The value "imWCS" indicates that the positional information comes from an astrometric fit to the stars in a scanned plate image.

EXPOSURS.date

• Synopsis: Midpoint date of this exposure
• Units/type: FITS time

If present, this is the geocentric midpoint UTC date-time of the exposure record.

EXPOSURS.date_src

• Synopsis: Source of the midpoint date information
• Units/type: string

This field is roughly the same as ctr_src, but referring to the origin of date and duration. Here, "imWCS" is not a possible value.

EXPOSURS.duration

• Synopsis: Duration of the exposure
• Units/type: seconds

This value may be missing.

EXPOSURS.expnum

• Synopsis: Logged exposure sequence number for this record
• Units/type: nonnegative integer

This field maps to expnum in an exposure list table. It may have a null value, if this row in the table corresponds to a WCS solution that could not be matched to a known exposure.

EXPOSURS.solnum

• Synopsis: WCS solution sequence number for this record
• Units/type: nonnegative integer

This field maps to solnum in an exposure list table. It may have a null value, if this row in the table corresponds to a logged exposure that could not be matched to a WCS solution.

EXPOSURS.u_date

• Synopsis: Estimated uncertainty in date
• Units/type: days

If present, this corresponds to the time_accuracy column in a lightcurve data table. See that documentation for details.

PEOPLE.name

• Synopsis: The name of the associated person
• Units/type: string

The name of a person associated with this plate. This name will be in the standardized form used by Starglass, and can be submitted to web APIs such as GET /astronomers.

PEOPLE.notebook

• Synopsis: The PHaEDRA notebook with the plate mention
• Units/type: string

This is either the identifier of the PHaEDRA notebook associated with a plate mention, or the special string "*curator". If the former, it will have the form phaedraNNNN. If the latter, it indicates that this record corresponds to a name mention detected in the Plate Stacks Curator’s comment record associated with this plate.

PEOPLE.page_num

• Synopsis: The page number with the plate mention
• Units/type: positive integer

For PHaEDRA mention records, this gives the page number on which the mention occurred. This information can be used with the GET /notebooks/{notebook_id}/{page_num} web API to obtain a link to the photograph of the page in question.

For curator-comment records, the value should be ignored.

Note that "page number" is a slight misnomer; better would be "image sequence number". The numbers often map to page numbers, but sometimes get out of sync.

PHOTOS.kind

• Synopsis: Whether this is a plate or jacket photo
• Units/type: string, "jacket" or "plate"

This indicates whether the this row documents a photograph of the plate itself, or of its paper jacket.

PHOTOS.portion

• Synopsis: Which portion of the plate/jacket was photographed
• Units/type: string

This will take on one of the values: "all" (everything), "t" (top), "b" (bottom), "ll" (lower left), "lr" (lower right), "ul" (upper left), "ur" (upper right). If the portion is (e.g.) "ul", that does not guarantee that the other three corners were also photographed; blank areas were skipped.

This information can be used with the GET /plates/p/{plate_id}/download web API to retrieve the photograph in question.