← Research

Research note · September 2, 2026

What automated image descriptions cost, at 5,000 objects and at 500,000.

The same accessibility job costs nothing at one scale and hundreds of dollars at another, and the right tool is completely different at each. Measured prices and throughput as of September 2026, for collections managers deciding whether this is affordable.

linkedcultureaccessibilitywcagmuseumsculturalheritagecollections


Prices and measurements in this note were verified on September 2, 2026. Every number here has a shelf life of roughly a year. Model prices have fallen by more than half annually for three years running, free tiers get renamed, and at least one service in the comparison below no longer does what its name suggests. Treat the structure of the argument as durable and the figures as perishable.

Many museum collections online carry no alt text. Not bad alt text: none. The image is published, the catalog record beside it is meticulous, and a visitor using a screen reader is told "Untitled" or nothing at all.

That is not universal, and I have since found the exceptions matter more than I expected. Getty publishes real visual descriptions on 52,452 of its records. The Museo Egizio has written excellent ones for about 900 objects. If your collection is one of these, the first job is not generation, it is finding out what you already have.

That is not a failure of care. Writing alt text costs staff time, the cost scales directly with the size of the collection, and it is the first line cut from a digitization budget. A national museum with an accessibility office manages some of it. A regional museum with one part-time collections manager and a catalog exported from a system bought in 2004 manages none.

So the practical question is not whether machine-generated descriptions are a good idea in the abstract. It is what they cost, and whether that number is small enough to stop being a reason not to.

The answer turns almost entirely on how many objects you have.

Start by checking what you already own

Before spending anything, look at what your own collection management system already stores, because some of it may already be alt text and some of it only looks like alt text.

I checked the Art Institute of Chicago's public API, which is unusually well built. In a sample of 400 records, 395 carried a thumbnail.alt_text field. That looks like a solved problem. It is not:

"A work made of pen and black ink and black watercolor over graphite, with touches of white opaque watercolor."

That is the medium field wrapped in a sentence. It is present, it is technically populated, and it tells someone who cannot see the object precisely nothing about what is depicted. 90 percent of the sampled alt text was this pattern. The remaining 10 percent were clearly written by a person and are excellent:

"Still-life painting, fish, open oysters, eel, lemon on tablecloth."

The Cleveland Museum of Art publishes a description field, which is curatorial and art historical: who the maker was, what the work commemorates. Valuable, and not a description of the image.

Getty is the opposite case and the one that surprised me. Their catalog carries an "Object Description" typed as a description, and it genuinely describes the picture:

A man is standing on a street corner selling pens and other small items. He has a dog with him, perched on a box, wearing a small hat.

That is alt text in everything but name, and it exists on 52,452 records. I had been treating the same field as curatorial context because that is what it holds at Cleveland. The lesson is that description means something different at every institution, and you cannot infer it from the field name.

The lesson for a collections manager is narrow and useful. Run a count against your own data before budgeting anything. Separate the fields that describe the object from the fields that describe the image. You may find, as I did, that a field labeled alt text is 90 percent boilerplate, or that a genuinely useful human-written subset exists and should be preserved rather than overwritten by a machine.

Whatever is already there and genuinely descriptive is the best material you have. It is free, it was written by a person, and it carries your institution's authority. Machine generation is for the remainder.

At 5,000 objects

This is the situation most museums are actually in.

RouteCostEffortWhat you get
Azure AI Vision free tier$0an afternooncaption, tags, objects, OCR
Gemini 3.5 Flash-Liteabout $3an afternoonfull custom fields
Claudeabout $26an afternoonbest quality
Self-hosted open model, rented GPUabout $2 of GPUdaysfull custom fields
Self-hosted on a laptop$0about 15 hours of runningfull custom fields

Microsoft's Azure AI Vision includes 5,000 free transactions per month, capped at 20 per minute, with every feature available: caption, dense captions, tags, object detection and text recognition. A 5,000 object collection fits inside one month of the free tier, permanently and legitimately, at no cost.

I want to be blunt about what that means, because it is the single most useful fact in this note. If your collection is under 5,000 objects, the cost of machine-generated alt text is zero and the work is one afternoon. No GPU, no procurement, no infrastructure, no vendor negotiation. The barrier is not money. It has not been money for some time.

Everything below this line is for people who do not have that luxury.

At 500,000 objects

My own corpus is 525,298 records across ten institutions, which is why I know these numbers rather than estimating them.

RouteCost for 500,000Wall clockNotes
Self-hosted open model, rented GPU$181 measuredweekscheapest, and by far the most work
Gemini 3.5 Flash-Lite, batch tierabout $315dayscustom fields, no infrastructure
Azure AI Vision$750dayscaption, tags, OCR, no custom fields
Claudeabout $2,575daysbest quality by a clear margin
Google Cloud Visionnot applicablesee below
Self-hosted on a laptop$18 of electricity64 daysfree, and absurd

A correction to something I published three days ago. My earlier note gave $46 for a corpus-sized self-hosted run. That figure came from a throughput measurement taken with a much shorter prompt. Measured properly, on a rented RTX 3090 at $0.155 per hour, the rate was 428 records per hour, which prices 500,000 records at $181. I have left the original note in place with a correction rather than quietly editing the number, because a note about cost transparency that silently revises its own costs is worth nothing.

A second update, from running it properly. The $181 assumed one image per pass. Batching eight images into a single forward pass measured 5.45x faster, and across roughly 32,000 records the real cost came out at $0.20 per thousand, or about $100 for 500,000. If you take one practical thing from this section, take that: the single biggest cost lever was not the card or the provider, it was how many images went through the model at once.

Google Cloud Vision belongs in this table only as a warning. It does not generate natural-language descriptions at all. It returns labels, detected objects, OCR and face data. If you evaluated it years ago as a captioning service, or remember it that way, check again before budgeting: labels are not alt text, and no amount of them adds up to a sentence a screen reader can usefully announce.

The grant that changes the arithmetic

Microsoft grants eligible nonprofits $2,000 per year in Azure credit, and the eligibility criteria explicitly name public museums and public libraries alongside 501(c)(3) organizations.

At Azure's rate, $2,000 covers 1.3 million images. It covers a 500,000 object collection twice over, and it renews annually.

This is the most consequential thing in this note for a large collection, and it is administrative rather than technical. The credits do not roll over year to year, so the sensible sequence is to prepare the run first and claim the grant second. If your institution operates under a fiscal sponsor rather than holding its own status, confirm which entity Microsoft registers the grant against before planning around it.

For a museum that qualifies, the entire cost question dissolves. What remains is the review problem, which no budget solves.

What the cheaper options do not give you

The prices above are not for the same product, and the difference matters more than the money.

Azure returns a caption, a set of tags, detected objects and any text it can read. That is genuinely useful and it is well suited to alt text.

Running an open model yourself means you write the instructions, so you decide what comes back. My own extraction asks for fifteen fields per image: a short alt text, a longer description, a transcription of any legible lettering and the script and language it is in, subject type, the concrete objects visible, a count of human figures and what they are doing, apparent materials, physical condition, viewpoint, setting, dominant colors, and a bounding box for the main subject.

None of that is available from a caption endpoint. Whether you need it depends on what you are building. For alt text alone, you do not. For search, for filtering by what is depicted rather than what the catalog says, for grouping objects by visual similarity, you do.

The model I use is Qwen2.5-VL-7B-Instruct, an open-weights vision-language model. The choice is institutional more than technical. Open weights mean it runs on hardware you rent by the hour, nothing leaves for a commercial API, no per-image fee accrues, and no vendor can change the terms or withdraw the service. For a collection that may want to reproduce this work in five years, that independence has real value. It is also small enough to run on a consumer graphics card, which is the only reason the self-hosted column is measured in hundreds of dollars rather than thousands.

The tradeoff is honest: a 7-billion-parameter open model is not as careful as a commercial frontier model, and most of the quality problems below follow from that choice.

A faster computer does not produce a better description

This is the most common misconception I encounter, and it costs people money.

A more expensive GPU runs the same model and returns identical text. It changes how fast the work finishes, not how good it is. What a larger card actually buys is the ability to run a larger model, and that does improve quality. The upgrade path for quality is the model, not the machine.

Two related findings from this week's measurements, for anyone tempted to optimize:

Running several images at once in parallel on one graphics card gained nothing. Generation is limited by memory bandwidth rather than by computation, so the work serializes regardless.

Reducing image resolution before analysis was worth 29 percent, with no loss of output quality. These models convert images to tokens in proportion to their pixel count, and most museum photography is far larger than the model can use.

Why a person still has to read the output

The first batch I generated produced descriptions that looked like fabrication. A commemorative medal was described as bearing the inscription "TREATY OF VERSAILLES". A photograph of a temple complex came back with text that was not legible in the image.

The cause was not invention. It was my mistake in how I asked. I had been passing the catalog title into the request to give the model context. Given a record titled Medal to Commemorate the Treaty of Versailles, a model this size cannot hold the line between "here is background" and "here is what you can see". It reported the title back as an inscription it had read off the object.

Removing the title fixed it. The same model, shown the image alone, correctly read a pub sign in a street scene and correctly transcribed a French caption with its accents intact.

I dwell on this because it is the failure that should shape institutional policy. A wrong description of a painting is a small embarrassment to a sighted visitor, who can look at the painting and see that the text is wrong. To a blind visitor it is false information about an object they have no other way to examine, delivered in the only channel available to them. The asymmetry is total.

A second pattern held across every version of my instructions, and it is worth knowing before commissioning this kind of work. A model reliably follows the shape you give it and unreliably follows the rules you give it. Ask for a structured response with fixed fields and it returns a valid one every time. In this week's run, 300 out of 300 records came back as valid structured data. Tell it in the same breath never to name a specific place, and it will still occasionally hand back "The Great Sphinx of Giza and the Pyramid of Khafre are shown in a sepia-toned photograph", which breaks two stated rules in one sentence.

Quality does not come from a cleverly worded instruction. It comes from what happens to the output afterward, and from someone checking.

Building the review tool is the part nobody funds

Some years ago, working with objects from a large federal collection, I built a review interface as a prototype: existing alt text listed for a human to assess, with a button beside each record that called Azure for a better suggestion on demand. A person could see what was there, see what a machine proposed, and accept, edit or reject it.

It worked. It was not adopted. There was no appetite for it at the time.

I include this because it is the most useful thing I can tell a collections manager, and it is not a technical finding. The generation is the cheap, easy, solved part. The review is the expensive, slow, unsolved part, and it is where these projects actually die. Not because the interface is hard to build, but because reviewing several hundred thousand descriptions is real staff time, and staff time is exactly what was missing when the alt text was not written in the first place.

Anyone selling you automated alt text is selling you the easy half.

What makes review tractable, in my experience:

Not every record needs the same attention. When the model encounters lettering it cannot read reliably, it can be instructed to say so rather than guess. That subset is where a reviewer should start, because it is where the model has flagged its own uncertainty.

Order the queue by who can actually reach the record. Describe the objects that visitors land on first, not whatever order the database returns. A perfect description on a page nobody can navigate to helps nobody.

Mark everything unreviewed from the moment it is created, and record approval as a separate act by a named person. Absence of objection is not approval.

And accept that "reviewed" will never reach 100 percent. It does not need to. A collection where the most-visited 5 percent is human-verified and the remainder is machine-generated and clearly labeled is enormously better than one where everything is "Untitled".

Record which machine said what

If a description is going to be read aloud to someone who cannot check it against the image, you need to be able to say exactly where it came from. Every description I generate stores the model that produced it and who provides that model, the version of the instructions and a fingerprint of their exact wording, the version of the cleanup rules applied afterward, when it was generated, and whether a human has reviewed it, which begins as no.

One correction fell out of taking this seriously. Each image also gets a color palette, measured directly from the pixels by ordinary arithmetic rather than produced by the model. I had initially stored that alongside the model's output and attributed it to the model. That is a false statement in a provenance record. "Which model produced this information" must have exactly one true answer for every field, so the palette now carries its own producer and is marked as not applicable for human review. A measurement is not something a person checks the way they check generated prose.

The distinction turned out to matter for quality too. Asked to name colors, the model says "sepia", "brown", "black". Measured from the pixels, the same photograph is 33 percent a particular dark olive, 23 percent near black, 17 percent a warm gray. The words are useful for searching. Only the numbers support comparing one object to another.

What I would tell a collections manager

Under 5,000 objects. Use Azure's free tier. It costs nothing, it will always cost nothing at that scale, and you can start this week. Spend your effort on the review process, not on the generation.

5,000 to 100,000 objects. Still a commercial API. At $1.50 per thousand you are looking at $7 to $150. That is a rounding error against the staff time already spent on the catalog records, and it requires no infrastructure. If you are a nonprofit, apply for the Azure grant and it is free.

Over 100,000 objects. Now the comparison is real, and it is between roughly $750 on a commercial service and roughly $181 running an open model on rented hardware. I chose the second, and I would caution anyone against assuming that saving is free. Capturing it took several days of fighting rented-GPU reliability, and at any realistic hourly rate that engineering time exceeds the difference. I did it because I wanted control of the output fields and because the tooling has value to me beyond this one job. If you simply need alt text, pay the $750, or apply for the grant and pay nothing.

If you want to see what one complete collection looks like when this is finished, including where the model was clearly worse than the museum's own curators, that is written up in Describing 5,228 museum objects from the photograph alone.

In every case. Budget for review, not for generation. Label machine-generated text as machine-generated, everywhere, permanently. Keep the model's raw output so you can improve your cleanup without paying to regenerate. And check what your own system already stores before you spend anything at all.

The expensive part was never the model. It was finding out what the model actually does, and building something honest enough to admit it.

---

Measurements in this note come from my own corpus of 525,298 records across ten institutions, and from runs conducted between August 28 and September 2, 2026. Pricing was verified against vendor documentation on September 2, 2026. I expect most of these figures to be wrong within a year, and I intend to revisit them.