Storing a Captured Image
The engine captures a frame; then what? A single image has to become a durable blob, a queryable metadata record, a thumbnail, a message to the archive, and a live update on the operator's screen. The image storage services in the engine do all of that in one pass, and each write lands in a store you've already met.
The one idea to hold on to
Saving one image fans out into four coordinated writes, wrapped by a small family of
storage services (SingleImageStorageService, PanoImageStorageService,
PreStitchedImageStorageService, all extending BaseImageStorageService):
Reading SaveSinglePhotoAndThumbnail, the sequence is: upload the image blob with the camera's
PTZ position attached as blob metadata, write a SingleImageMetadataEntity, enqueue for
archive when archiving is on, and push the metadata to the operator's group over SignalR.
Each write reuses a store you know
- Blob — via the Infrastructure
ImageStorageRepository; the PTZ position rides along as blob metadata so an image is self-describing. - Metadata —
_singleImageMetadataRepo.CreateAsync(...), which automatically writes the index-table row too (the dual-table index pattern from the Infrastructure Table Storage docs). One call, two tables, so retention stays cheap later. - Cache queue —
SendMessageAsynconto acache-*queue, but only when archiving is enabled; the consumer is CameraOperation's PublishBlobFunction. - SignalR — the same real-time channel the frontend uses to show the freshest frame.
The cache-queue enqueue is gated on the archive flag. If an image is stored and served but never shows up in the long-term archive, check whether archiving was enabled for that capture before assuming the archive pipeline failed — the image storage path completes successfully either way.
Wrapping up
Storing a captured image is a four-way fan-out — blob (with PTZ metadata), a self-indexing metadata row, a conditional archive hand-off, and a real-time SignalR push — coordinated by a small family of storage services over a shared base. Every write reuses an Infrastructure store, and the metadata's automatic index write is what makes retention affordable.
Those images don't live forever. Next: Retention Cleanup.