New cutout service behavior, or how deep would you like your slice of cake
As of the most recent Patch Thursday (2025-12-18 ) our cutout service (at the API endpoint https://data.lsst.cloud/api/cutout/) has new options and its default behavior has changed.
Rubin image data consists of a number of planes: not only the typical pixel, mask, variance, WCS planes but also provenance, PSFs, and so on. In the previous behavior of the cutout service, when you asked for a spatial cutout of the data you got a slice all the way down the cake, including the large PSF and provenance layers. While this is arguably the most correct behavior (when you ask for 1/8th of a cake you expect to get a cut all the way down), most users use the cutout service for purposes for which image pixels, WCS and the primary header are sufficient (to flog the analogy to death, they are mostly interested in the icing).
The cutout service now supports a parameter, CUTOUTMODE, controlling how much of the image data is returned during a cutout.
-
Image: returns only the pixels with a WCS and the primary header. This is the new default behavior if no parameter is specified -
Masked-image: this returns the above plus the mask and variance planes -
Exposure: the kitchen sink - all the above plus the PSF and provenance planes. Use this option to reproduce the old default behavior.
In PyVO this corresponds to the datalink services cutout-sync, cutout-sync-maskedimage and cutout-sync-exposure
The reason for this change is that particularly for deep coadd images, the PSF and provenance planes greatly increased the size of the results. Since most users are satisfied with the pixel plane, the new default behavior both improves the performance of the cutout service for the individual user, and it significantly increases the throughput of the service across all users.
The tutorial notebooks available through the RSP Notebook service have been updated to reflect this behavior. As with all Data Management code, you can find the source for the cutout [on Github](https://github.com/lsst-sqre/vo- cutouts).
Improved FITS WCS approximations coming soon
More nuances our complicated beautifully rich image data: the World Coordinate System on our single visit and difference images is represented as a series of mappings for ultimate astrometric fidelity. However the FITS WCS standard is not capable of representing an exact serialization of these mappings, so we use a TAN-SIP projection that is sufficient for visualization and object-finding (though not precision astrometry).
We have determined that the WCS approximations stored in the FITS headers are not as accurate as we originally believed, especially in the outer detectors… We will be releasing new versions of the FITS files early in the New Year with improved approximations. For precision astrometry, we strongly recommend interacting directly with our data products using the LSST Science Pipelines.
You can read more about this in the
Known issues and subtleties — DP1 documentation and we will post an announcement when the new files are available, including how to get access to the old versions if you really need them, as by default you will get the new improved files when accessing RSP services.
New Settings UI
You may have noticed the RSP settings page available through your account menu (the one you get by clicking on your username on the data.lsst.cloud landing page) recently received a significant revamp in style and no longer looks like something a telex spat out circa 1981. There are now separate Settings sections for account settings, access tokens, active sessions and (most) active quotas. As with everything else RSP, many more improvements are planned.
Bear with us while we update the documentation at rsp.lsst.io to reflect the new UIs.
More space! More queries! More everything (only not just yet)
Speaking of quotas, we are always looking to increase the resources on data.lsst.cloud to provide maximum utility to our community, based on current utilization and usage patterns.
The good news is of the most recent Patch Thursday, everyone’s disk quota went up by about 10% from 36GB to 40GB.
Rate limits to the TAP server went up by a factor of 5 (from 200 to 1,000 calls per minute). Note this is not the rate of TAP queries you can do, as your TAP clients typically do an order of magnitude more calls to the TAP server (for auxiliary information, polling for status etc) for every query you submit. We are working on a better explanation of how rate limits are applied to the API aspects, but you can never go wrong by asking services to do things only as fast as you’re getting results back.
The bad news is - actually there is no bad news. In fact we hope to relax more limits in 2026 and beyond as we improve the efficiency of our services and tune our resource allocations better.
To say this was a big year for us at Rubin Data Services would be an understatement; thanks to all of you working with the RSP Data Preview, we are getting a lot of excellent real-world data to help us decide where to concentrate our software development efforts in the future.