Online Proofing Gallery for 100MP Medium Format Files

Compression happens on your machine, in the browser tab, before anything is sent. The browser decodes the image you selected at its full resolution, resizes it, and encodes a proof JPEG. Only that proof travels. Nothing about your original file is stored.

That design is why the plan has no storage tiers. It also means the heavy lifting happens in a browser, which has limits that a desktop RAW processor does not.

Here is the honest limit, and it matters most to exactly the readers of this page. There is no file-size guard and no megapixel guard on the upload path. Whatever you select is handed to the browser to decode at full resolution. If the browser refuses to decode it, that file is skipped, and the studio view reports a count of failures rather than telling you which file failed and why. So a studio that drags 100-megapixel originals straight into the uploader can lose photos quietly: the gallery publishes, the numbers look close enough at a glance, and a frame the client needed to see is simply not there.

We would rather write that down than let you find it on a delivery day. The fix is cheap and it is a better workflow anyway.

Do the downsizing in the tool that is built for it. Your RAW processor decodes medium format files natively, uses the full machine, and gives you a repeatable recipe. The browser is a fine place to shave a normal JPEG. It is the wrong place to unpack a 100-megapixel capture a few hundred times in a row.

The export step, whatever you shoot on:

• Export JPEG, not TIFF or PSD. The gallery is a JPEG host. A 16-bit layered file has nothing to gain here and everything to lose in the handoff.
• Convert to sRGB on export. Medium format work usually lives in a wide working space. Browsers and phones do not reliably honour that, and a client who sees flat, desaturated proofs will tell you the edit is wrong when it is not.
• Resize well below the sensor's native resolution. A proof is for judging a frame, not for printing it. Set a resize in the export recipe and leave it set. Keeping proofs small is also what stops a client from treating the proofing link as delivery.
• Save it as a preset and stop thinking about it. A Capture One process recipe, a Lightroom export preset, a Phocus export setting. One recipe per studio, used for every proofing round.
• Sharpen for screen, lightly. Downsizing a 100-megapixel file that far softens it. A small output sharpening pass makes proofs read the way the master reads.

If you work in Lightroom Classic, the plugin removes the decision. It is both an Export service and a Publish Service, the published collection is the gallery, and it forces sRGB JPEG export settings rather than offering them. Files leave Lightroom already in proofing shape.

If you work in Phocus or Capture One, build the recipe once. Our Phocus walkthrough covers the export side in more detail.

A medium format job produces three different things, and they belong in three different places. Confusing them is what makes people ask a gallery platform to be a backup.

Row one is the one people want to argue with, so let us be blunt about it. Your RAW files stay with you. clientgallery.io is not your backup, not your DAM and not your archive of record. A studio that shoots 100-megapixel files needs a real backup strategy on its own hardware or with a service that sells storage, and that would be true no matter which gallery platform you used.

Delivery of finished files is a separate, paid mechanism from proofing. You upload one full-resolution ZIP per gallery. It stays live for 3 days per handoff, and you can re-upload it at any time, as many times as the client needs. The client's download is logged and served from a short-lived signed link. The gallery itself does not expire; only the ZIP does. Keep that distinction exact when you write the delivery email.

The ceiling is 100 GB of standing ZIPs across the whole account, counted over every gallery at once. At normal wedding file sizes that is a lot. At medium format retouched-TIFF-turned-JPEG sizes it is not, and you should plan for that. Run the arithmetic against your own average delivery instead of ours.

Read that as a working window, not as storage. The 3-day life of a handoff is the point: the ZIP is up while the client is collecting, and then the space comes back for the next job. Because you can re-upload at any time, a client who misses the window gets a new link, not a lecture. What you should not do is treat those 100 GB as a place to park a year of finished work.

Delivering 100-megapixel files to clients goes further into the handoff itself.

Proofing has its own ceilings, separate from the delivery quota above. They are abuse tripwires, not sales gates, and they are the same on every paid account because there is only one plan.

Hitting 1,000 photos in one gallery is unlikely on a medium format job, and if you do, the refusal tells you to split into another gallery. Galleries are unlimited, so that costs nothing but a second link. The 250 GB proof ceiling applies to compressed proof JPEGs, which is why exporting sensibly sized files matters twice: it keeps the uploader out of trouble and it keeps you far away from the cap.

If what you actually want is a platform that stores your RAW files, you want a company that sells storage, and you should buy it from one. SmugMug is the honest example to name, because it publishes the price. Its plans page lists Direct at "$20.00/MO" with unlimited JPEG storage, at the annually-billed rate, and sells RAW storage as a paid add-on: "up to 1TB of RAW files for just $10/mo", then "$6/mo for each additional TB". That is a fair deal for what it is, and it is a different product from ours.

Pick that kind of product when the masters living off-site is the requirement. Pick clientgallery.io when the requirement is a clean, unbranded proofing and delivery surface at a flat price, with the masters staying under your control. A studio can reasonably run both, and plenty do: archive where archiving is sold, proof where proofing is good.

One more honest note. We publish no load-time measurement, so we will not quote one. What we will say is that the reason proofs are compressed in your browser before they leave, rather than uploaded whole and resized later, is to keep client-side viewing light. If you have arrived here from a platform where big galleries crawl, the slow gallery guide explains what is usually causing it.

• SmugMug, Plans and pricing, https://www.smugmug.com/plans, fetched 8 September 2026.