The Big Experiment: building my own CDN-based HDR image delivery system

My ideal outcome would be for established photography services such as SmugMug to embrace these capabilities and make them available to their customers sooner. Photographers should be able to benefit from true HDR without having to build their own publishing system, while continuing to deliver carefully prepared SDR images to people who need them.

I also hope the experiments will help other enthusiasts explore similar systems. I have demonstrated a working approach within my tested setup. Sharing the findings, including the difficulties, could make it easier for others to develop efficient SDR and HDR delivery for their own websites.

No. This is an experiment in image preparation and delivery, not an attempt to recreate the full SmugMug service. The aim is to show what can already be achieved with modern formats and a relatively focused system. Matching its image-size tiers also gives me a useful basis for comparisons at the same dimensions.

I would much prefer established providers to seize the opportunity. If they do not adopt these capabilities within a reasonable timeframe, I think there could be an opening for an enthusiastic startup to offer them. That is a possible commercial opportunity, not a claim that this experimental system is already a replacement for an established service.

No. SDR delivery is an important result in its own right. My tests have shown opportunities to compress SDR photographs efficiently with AVIF while controlling their dimensions, quality and output sharpening. That matters even if a visitor never uses an HDR display.

For combined images, I use an independently created SDR image as the base and a gain map to reconstruct the HDR appearance. The intention is to preserve the photographer’s SDR presentation while adding HDR. My results have looked good in the Chrome and Safari configurations tested; they are not a guarantee for every browser or display.

The JPEG delivery I have been comparing with provides a useful reference. Smaller suitable AVIF files can reduce download requirements, but whether a whole service is faster also depends on caching, decoding and the viewer. A fair comparison must measure those as well as file size.

No. I have chosen Q70 for the new combined AVIF files because I am pleased with the balance of quality, size and responsiveness. This is a photographic preference, not the only useful way to configure the system. Another website owner might reasonably give more weight to reducing page size.

My new fast-delivery gallery uses Q50 for both the SDR base and the full-resolution gain map, with 10-bit 4:2:0 colour. Across test photographs matching 2048-pixel dimensions, my SDR JPEG Q90 reference images totalled 9.87 MB, standard combined Q70 AVIF 7.18 MB, and fast combined Q50 AVIF 2.92 MB!

In my viewing of the full-size Q50 gallery, the photographs still looked very good, with no noticeable banding or major artifacts. I think many viewers would be happy with them. Both galleries now offer the same delivery sizes through 5120 pixels. The fast gallery is a permanent experiment for readers to judge, and I will broaden it with more photographs.

No. The wider objective is efficient image delivery throughout ordinary websites. The same prepared images can support both a gallery and an embedded photograph within an article, with a higher-resolution view available when someone clicks. There is no need to generate a separate set of files for every website using them.

The architecture separates image preparation from page publishing. My processing creates the approved sizes, compression and output sharpening while retaining the masters. A content delivery network stores and serves those finished files. The page tells the browser which versions are available, and the browser selects a suitable one for the displayed size and pixel density.

This gives me control over photographic processing without asking WordPress to regenerate the images. The live gallery now provides responsive embed codes to paste into a Gutenberg Custom HTML block. The browser selects an inline image using the page layout and pixel density, rather than sending a fixed 2048-pixel file to every device.

A leaner page framework, such as my move to Gutenberg, and better image delivery address different parts of the same problem. Combining appropriate dimensions with suitable compression may substantially reduce the image payload of photographic pages.

No. The current recipe makes several choices in favour of photographic quality. Changing the AVIF quality number is only one of the controls available. Colour sampling, gain-map resolution, image dimensions and encoding effort also influence the result, and they should be tested separately before combining changes.

Colour sampling. My standard Q70 recipe uses 4:4:4 for the base and gain map. The Q50 fast experiment uses 4:2:0 for both and has produced attractive results in my viewing. This gives a practical second delivery choice while retaining the standard recipe.

Gain-map resolution. I currently retain a full-resolution gain map because the reduced-resolution versions visibly lost important HDR detail in my tests. Organ pipes, gold decoration, shields and stonework were particularly revealing. A smaller map may still be acceptable for some photographs or viewing sizes, but it must be assessed in the reconstructed HDR image. An SDR preview alone cannot establish that the HDR result is good enough.

Map encoding quality. The base and gain map have separate quality settings. The standard recipe uses Q70/Q70; the fast experiment uses Q50/Q50. Both retain full-resolution gain maps. Reduced-resolution maps remain a possible future experiment, but I am not pursuing that now because the present savings are already substantial.

Encoding effort. My pipeline prepares the files before publication, so it can spend more time encoding without making visitors wait for that work. I use encoder speed 3, allowing a more thorough compression search than the faster setting tested earlier. In those tests, it improved the measured quality and often reduced size. It did not make every file smaller at the same quality setting, and the further move to speed 2 did not justify the additional time for my chosen workflow.

This flexibility is part of the value of the architecture. I can choose a quality-oriented recipe for a portfolio, or investigate a lighter recipe for ordinary web pages, while retaining the original masters. My present settings demonstrate one successful balance; they do not establish the smallest acceptable payload. Any new balance should be judged on SDR and HDR appearance, file size and actual display performance.

No. AVIF is my current delivery choice, not a permanent constraint on the architecture. I retain the independently produced SDR and HDR masters separately from the files prepared for visitors. That lets me generate new delivery versions as formats, browsers and audience requirements change, without having to recreate the photographic edits.

The broader aim is to choose suitable delivery formats for the audience at the time. The platform could be extended to offer different formats from the same masters, but each would need appropriate encoding, metadata, responsive selection and testing.

My earlier gain-mapped JPEG web experiments did not meet my website delivery priorities. I have since produced and successfully uploaded an Instagram set using an independent encoder. Gain-mapped JPEG is now a working destination-specific output, while AVIF remains my website choice. Conventional gain-mapped JPEGs use an 8-bit JPEG base with additional gain-map information for HDR reconstruction.

I am concentrating on AVIF because of the combination of image quality, manageable file sizes and successful SDR-base gain-map tests in my Chrome and Safari setups.

JPEG XL is a promising candidate for a future delivery experiment. I already use JPEG XL files among my HDR masters, but using a format for a master is a separate decision from delivering it to website visitors. Keeping the masters independent of the delivery copies gives me room to explore both.

Safari added JPEG XL support in version 17. That is a useful starting point, rather than proof that every SDR or HDR presentation I want will work identically across browsers and devices. A delivery trial would need to verify the particular files, colour handling and HDR behaviour, as well as what visitors receive when their browser does not support the chosen format. [2]

A JPEG XL comparison gallery would therefore be a useful next experiment. I could use the same source photographs and output dimensions to compare appearance, file sizes, decoding and perceived loading speed against AVIF. I should test equivalent visual quality or equal byte budgets, rather than matching unrelated encoder quality numbers.

If JPEG XL, or another format, offers a better balance for my visitors in future, the pipeline can evolve to use it. The lasting investment is in the masters and controlled preparation and delivery process; AVIF is the format I have currently selected for that process.

No. There is an important difference between developing and testing the system and using the resulting workflow. I have spent time experimenting with settings and investigating browser behaviour, but publishing an album does not require repeating that research or manually preparing every delivery file.

For a new combined gallery, I prepare the SDR and HDR masters, put the matched photographs in the appropriate album folder and run the publishing process. The system matches pairs by filename. It then generates the delivery sizes, applies the configured output sharpening, calculates and encodes the gain maps, and creates the AVIF files using the chosen settings. It also creates the gallery data and uploads the prepared assets to the CDN. The gallery viewer uses that information to display the album and select suitable viewing files.

I do not have to resize, sharpen, encode and upload each version individually. Publishing a Gain Map album now prepares its standard Q70 AVIF gallery, companion Q50 fast AVIF gallery and Instagram gain-map JPEG gallery from the same pairs and order. The live gallery also generates responsive website embed code, including 25 pixels of spacing above and below the image.

Some input remains deliberately photographic. I choose and edit the masters, keep the paired filenames consistent, decide the order and check the results. Publishing is currently started by me. Photo order can be specified in an order.txt file; a simple editable gallery-description file has been proposed but is not yet implemented. The initial technical setup also requires more knowledge than signing up for a hosted photography service.

There is scope to streamline the process further as I establish what is useful. Easier ordering and descriptions, clearer validation of image pairs, and simpler publishing controls could reduce the remaining administration. The aim is to turn the successful experiments into repeatable defaults, so I can spend more time working on photographs.

Someone could potentially develop this kind of architecture into a commercial product, with guided setup, reliable processing and support. That is not what I am currently doing. This is a personal experimental system intended to help me publish my photographs and share the findings. It is already substantially automated, and it may become simpler to operate; it should not be mistaken either for a wholly manual exercise or for a finished product that anyone can install without assistance.

A reader first receives an image suited to its space in the page and the screen’s pixel density. Clicking opens a black-background viewer on the same page, requests native fullscreen where supported, and selects an appropriate larger file from the prepared sizes through 5K. A second click or the close button returns to the article. The larger viewing image is requested when the reader chooses to inspect it.

This is a core requirement for ordinary websites as well as galleries. A 1024-CSS-pixel article can use a 2048-pixel image on a 2× display, while smaller layouts have smaller candidates available. The enlarged view is sized independently of the article width. These benefits apply to SDR photographs as well as gain-mapped HDR images.

The most obvious difference in my viewing was receiving enough image pixels for a high-resolution monitor. My initial Q50 trial stopped at 2048 pixels, so fullscreen viewing on a 5K display made it look softer. After matching the size ladder through 5K, my assessment improved substantially.

Efficient delivery means choosing sufficient resolution for the viewing space as well as suitable compression. The aim is to avoid both unnecessary downloads and enlarging a small image beyond the detail it contains. Keeping private masters independent of delivery settings lets us continue refining that balance.

This includes Retina phones, not just large desktop displays. In these tests, sufficient pixel resolution with stronger compression was preferable to enlarging a smaller image encoded at a higher quality setting.

Not necessarily. The useful comparison is the total bytes stored against a defined alternative, rather than the number of files. An early study provides a concrete example: all 168 Q50 delivery files, covering 12 sizes per photograph, occupied 32.47 MB together. That is less than the 36.39 MB used by just the fourteen largest 5K Q70 files.

Those sizes give us flexibility to match the viewing space and display density. Visitors need only download the suitable version, with a larger image available when they choose to inspect it. This reduces unnecessary page bloat: visitors should not have to download image data that their current view does not need. Across phones, tablets and desktops, selecting suitable files can significantly reduce average page weight compared with sending everyone one large compromise version.

Yes, I think it points towards a very promising direction: websites that are quick and economical to browse, yet can reveal high-quality photographs and greater detail when a visitor wants them. The aim is to minimise unnecessary page weight while making the most of each device and display.

This starts with the page itself. Moving away from a heavy page builder towards a simple theme and Gutenberg gives us an opportunity to reduce unnecessary layout code, styling and scripts. My image delivery work complements that approach by addressing the photographs themselves: their compression, dimensions and the point at which larger versions are downloaded.

The page initially provides an image suited to its displayed size and the screen’s pixel density. A reader who wants a closer look can click to open a larger view on the same page, with an appropriate higher-resolution file delivered at that point. High-quality viewing remains available without requiring every visitor to download the largest image merely to read an article.

Behind this, I retain the photographic masters and automate the preparation of delivery files, including resizing, output sharpening and encoding. The same prepared images can serve both galleries and ordinary web pages through the CDN. This gives me control over the photographic result and keeps image preparation separate from the website’s page-building system. It also leaves room to change delivery formats as browsers and codecs develop.

My experiments give me practical evidence for that direction: useful SDR and HDR presentation, attractive results at substantially smaller file sizes, and access to more detail without making every page carry the largest files. The benefits extend to ordinary SDR photography; HDR adds another opportunity within the same approach.

The vision is a simple, responsive website that delivers what the visitor needs for the current view, then offers more when requested. I can seek lower average page sizes and faster delivery while retaining a rich visual experience. These results suggest a strong basis for that architecture, with whole-page performance across more devices and connections providing the next test of how far the combined benefits can go.

An attractive HDR view does not tell me whether the SDR version is the photograph I want other viewers to see. An HDR monitor can be used to assess both, but I deliberately check the SDR rendition separately rather than judging only the HDR display.

In my own editing, Camera Raw’s secondary SDR controls within an HDR edit have not offered the flexibility I get from finishing the SDR photograph independently. My workflow starts with the SDR edit, saves that approved master, then finishes and saves the HDR version with matching geometry. Neither appearance is an afterthought: the gain map is generated from the two approved versions.

This is a creative-control requirement, not a claim that every photographer using another workflow neglects SDR. It also does not promise mathematically lossless delivery: resizing and compression still affect viewing copies, and Instagram processes uploaded files. What I retain is control over the intended appearance of both inputs, without needing a paid Photoshop export plugin.

Instagram is now a working output of this system. The same album produces responsive AVIF for websites and Instagram-specific gain-map JPEGs. I am not recommending JPEG gain maps for universal website use: AVIF remains my preferred balance there. The Instagram JPEGs meet a different need, at my tested 2160 × 1440 size with output sharpening and a full-resolution colour map.

When uploading, select Original ratio and avoid Instagram cropping or edits. Check the finished post, since the upload preview may look SDR. Instagram still controls its processing and display; independently edited masters give us control over the input rather than a guarantee of unchanged pixels after upload.

This is a complete-workflow approach, not Greg Benz versus Mark Heath or JPEG versus AVIF! My result demonstrates a specific route: retain the two finished masters and automate several outputs without buying an additional export plugin. It is a working personal system, not yet a packaged product for everyone to install.