A cloud viewer streams a study to whichever screen the reader happens to be using: a workstation in a fixed reading room, a laptop at home, a tablet on a mobile unit. Two products that both call themselves a cloud viewer can pass the same quick sales walkthrough and still differ completely in the one place that walkthrough never shows: where the pixel pipeline actually executes. That single fork decides what crosses the network for every study, what a reader can do to the image without waiting on a server, and where the compute cost lands.
This is not a detail vendors describe differently by habit. DICOM PS3.18 puts a study retrieved as a finished picture and a study retrieved as pixel data in separate resource categories. A buyer can test which one any given viewer uses simply by watching what comes back over the wire.
What a Cloud Viewer Actually Streams
DICOMweb, the REST-based retrieval standard nearly every one of these viewers is built on, does not define a single way to get a study out of an archive. PS3.18 separates Instance Resources, which hand over the DICOM instances themselves, from a distinct category called Rendered Resources. The standard is specific about what a Rendered Resource does: it is used “to retrieve representations of a DICOM Resource rendered as appropriate images, videos, text documents, or other representations.”
The stated purpose is to give a browser a shortcut. Its “primary use case is to provide user agents with a simple means to display medical images and related documents, without requiring deep knowledge of DICOM data structures and encodings.”
That word, rendered, is doing real work. A Rendered Resource does not hand the client a DICOM object at all. A server somewhere has already executed the rendering pipeline, windowed the pixel data, and produced a picture.
Retrieve the same study as an Instance or Bulk Data Resource instead, and nothing has been rendered yet. The server hands over the pixel data itself, and the rendering pipeline runs wherever the client happens to be. Both paths can be called a cloud viewer. Only one of them ships a finished picture.
Two Wire Formats, Not One
What crosses the network differs between the two paths, and the difference is not subtle. PS3.18 states plainly that “DICOM Instances may be converted by a rendering process into non-DICOM Media Types,” and that “Rendered Media Types are usually consumer format Media Types.” For a single-frame image, the standard requires every origin server to support at least one of those consumer formats: image/jpeg.
When that format is returned, the standard is exact about what it is: a “JPEG baseline lossy 8-bit Huffman encoded non-hierarchical non-sequential process.” A rendered stream, at minimum, is an 8-bit consumer image, not the study.
Retrieve Bulk Data or Pixel Data instead, and the object crossing the wire is different in kind. PS3.18 defines Bulk Data Resources as resources “used to retrieve data elements (typically containing large data, such as Pixel Data) extracted from DICOM Instances,” and Pixel Data Resources more narrowly, noting “Pixel data is a subset of Bulk Data.” Neither path forces the data down to 8 bits. A CT slice acquired at 12 or 16 bits per pixel can cross the wire at its native depth, compressed but not flattened into a consumer image format on the way.
That distinction matters the moment a reader needs to see something the server’s default rendering did not show. An 8-bit JPEG has already thrown away whatever density range fell outside the window the server chose. Bulk or pixel data retrieval has not made that choice yet.
Progressive and Lossy-to-Lossless Transmission
The bulk-data path also has an option the rendered path does not: choosing how the pixel data itself gets compressed for transit. DICOM’s own encoding rules note that “Annex A defines a number of Transfer Syntaxes that reference the JPEG 2000 Standard and provide lossless (bit preserving) and lossy compression schemes,” and a separate section confirms “the JPEG 2000 Image Compression Transfer Syntax allows for either lossless or lossy compression to be used at the sender’s discretion.” The sender, not the reader, decides how much of the original data survives the trip.
Newer transfer syntaxes go further than a single lossy-or-lossless choice. The High-Throughput JPEG 2000 Lossless RPCL syntax, DICOM states, “allows for progressive display of images, as well as retrieval of thumbnail images.” The mechanism behind that claim reorders the compressed data itself: “This sequences the resolution blocks so that lower resolutions can be read first.” A viewer built on this transfer syntax can paint a coarse version of a large study almost immediately, then refine it as more of the same stream arrives, all without a second request.
That option belongs to the bulk-data path specifically. A Rendered Resource returns one finished image per request, at whatever resolution the query parameters specified. Getting a coarser version first means asking again with different parameters, a second round trip rather than a continuation of the first.
Window and Level When the Pixels Are Not Local
Windowing looks identical to a reader on either path. Underneath, it is not the same operation. PS3.18’s rendering query parameters list window center, width, and shape as request-time values for a Rendered Resource, and the standard is explicit about what happens to them: “The set of transformations specified by the parameters in this section shall be applied to the images as if the parameters were a Presentation State.”
The server applies the transform and returns a new picture. There is no windowed pixel data on the client to begin with, only whichever rendered image the last request asked for.
Windowing performed against locally held pixel data works differently, because the client already has the study’s own pixel values, rescale slope, and intercept. Moving between a lung window and a mediastinal window on the same chest CT, something a radiologist does dozens of times per study, is a local recalculation against data already in memory. On the rendered path, the same move is a new HTTP request with new windowCenter and windowWidth values, answered by a server that has to run the transform again.
Neither model is wrong. A referring physician opening one image to confirm a result may never notice the round trip. A radiologist rewindowing the same series forty times in five minutes will.
Where the Rendering Pipeline’s Heaviest Work Lands
The gap widens past simple windowing. DICOMweb also defines Rendered MPR Volume Resources and Rendered 3D Volume Resources, and for the 3D volume case the standard describes a result produced “by applying thresholding, ray-casting, volume rendering, or other methods to display a volume of slice data as a three-dimensional projection.” Ray-casting and volume rendering are demanding work regardless of what executes them. Requesting one of these resources means a server somewhere is doing that work on the partner’s behalf, for every request, for every connected reader.
The alternative path sends the underlying slices and leaves reconstruction to whatever is running the viewer. A peer-reviewed comparison of rendering approaches for web-based medical imaging, published in the Journal of Digital Imaging, describes the tradeoff directly: “the server-side rendering technique alleviates the limitations of client-side hardware dependencies and software installation; however, the performance of server-side rendering relies heavily on network bandwidth and transmission latency.”
Moving the heavy computation off the client does not remove it. It relocates it to infrastructure the vendor has to build, size, and keep available, and trades a hardware requirement for a network one.
What Each Model Costs in Latency and Bandwidth
Neither path is free, and the cost shows up in different places. A rendered stream keeps each response small and the client simple, which favors a weak device on a decent connection. Every interaction still costs a round trip, so the cost scales with how much a reader interacts with the image rather than with the size of the study itself.
A bulk-data stream front-loads the cost. More data crosses the wire before a reader sees anything, and a slow or unreliable link, not the study’s size on a stable connection, sets how long that wait runs. Once the transfer lands, though, windowing, measurement, and reformatting are all local, and nothing about how a reader manipulates the image depends on the network again.
A partner choosing between the two is really choosing which cost its actual readers can absorb: server infrastructure sized for interactive round trips, or client hardware and bandwidth sized for one heavier upfront transfer.
Putting the Question to a Live Endpoint
None of this has to be taken on a vendor’s word. A DICOMweb endpoint answers directly: request the same study as a rendered resource and again as bulk data, and compare what comes back, in what format, and at what bit depth. Ask what happens, specifically, to a rewindow request: a new picture from the server, or a local recalculation. Ask whether the viewer supports a progressive transfer syntax for a large study on a slow link, or whether the first view a reader sees is already the only resolution on offer.
Two questions sit just outside this article’s scope and belong to it anyway. Whether a specific viewer component carries regulatory clearance for the reading it is used for is a separate and prior question. What to ask a vendor about a zero-footprint viewer works through it in full.
A device is not only judged by which pixel pipeline it prefers, either. What changes when the device in the reader’s hand is a tablet is its own evaluation, with its own answers.
The pixel-pipeline choice belongs to whoever builds the viewer. What EBM mAIn PACS® publishes is the surface underneath that choice: native DICOM C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment, described on EBM’s own integrations page this way: “Connect any modality or viewer without custom middleware.”
EBM takes a position on the network side of that trade. Its homepage sets EBM mAIn PACS® against cloud PACS on exactly this axis, listing “Requires reliable internet” and “No edge processing” on the cloud side and answering with “Works anywhere. Edge performance.” That is EBM’s own stated position rather than a neutral rating, and it is a claim about where the pixels sit, not about how a viewer renders them.
The page states its position on the architecture question directly: “No proprietary lock-in. EBM mAIn PACS® speaks DICOM and exposes the APIs partners need to embed imaging into their own products.” Where a partner’s own viewer runs its rendering pipeline is a decision that sits above that surface, and it stays the partner’s to make.
The architecture question does not disappear once a partner picks a vendor. It resurfaces every time that partner’s own product team decides how the next viewer feature gets built: as a new server-side rendering endpoint, or as a client that already has the pixel data it needs. Knowing which model a study streamed through is what makes that decision an engineering choice instead of a guess.