This page is a rough draft, or really an information gathering device at this point.

 

The basic concept is that the user will specify and image location, time, and shape. the butler retrieves the base image, and the cutout service cuts the requested area out of the base image. The initial versions of the cutout service are going to return rectangular images, but eventually the shape of the returned image will be arbitrary. The cutout service may wind up being part of the butler or not. I expect the cutout service will need to work closely with the butler and the mosaic service. There are several questions about the details.

 

  • What are the image cutout request formats?
    • At a high level, I expect a rectangular region centered around a point specified by RA, Dec, Epoch, and time with image height, width and rotation. This should help avoid a lot of the pitfalls with spherical coordinates.
    • At a low level, I expect a file name with upper left and lower right pixel coordinates.
    • How are complex shapes going to be defined
  • Is there existing nomenclature?  
  • What tools do we have to locate the base image? (butler)
  • What tools do we have to cut the image out?
  • Images generated will need header information.
    • We should support multiple file formats, but stating with FITS should be reasonable.
    • The header information should be consistent consistent with the header information.
      • Canonical header information? What is going to be consistent an important regardless of file type?
      • There will be a need for keywords to indicate that the image is a cut out, its source image, and what else?
        • The change in image size, location, may invalidate some keywords.
        • In the case of FITS files, would it be reasonable to include the source image header information in a separate HDU?

 

  • No labels

1 Comment

  1. Kian-Tat Lim

    I think there are two kinds of cutouts that we need to distinguish:

    • Non-resampled, original pixels, always rectangular with same scale and orientation/rotation as original image, possibly mosaicked (e.g. adjacent patches from the same tract in a coadd or even adjacent CCDs from the same exposure which can have nonuniform pixel spacing).
    • Resampled, possibly rescaled, possibly rotated, possibly mosaicked.

    The low-level primitives that are (or should be) available are:

    • Determine image(s) overlapping a point or region
    • Retrieve one or more original images or rectangular non-resampled subregions of original images
    • Rotate/warp/scale a single rectangular image into another rectangular image (with masking of unused pixels)
    • Assemble multiple (possibly overlapping) rectangular images into a single rectangular image

    Regions will generally not be more complex than spherical polygons as in sciSQL.

    Headers are a somewhat complex topic; we'll need to decide what metadata is copied, transformed, or deleted and then furthermore (separately) decide how to persist metadata as FITS headers.