Image processing at volume
Each image is small; the collection is not. How a pass over a very large image collection is described as one job on E31 Network, and why the inspection camera on the line is not part of it.
· 4 min read
IN SHORT
Image processing at volume is a pass of a model or pipeline over a very large collection of still images that already exist. E31 Network is being designed to take the whole collection as one job: the pipeline is the work, the staged images are the data, and the per-image results are the output. Compute is held for the pass and released when it finishes.
Image processing at volume is the case where a team has a very large collection of still images and a model or pipeline to run across every one of them. The collection might be a product catalogue that needs tagging, an archive of scanned pages that needs reading, aerial imagery that needs segmenting, or a library of photographs that needs deduplicating and captioning. Each image is small. The collection is not.
This is a natural batch job. The images already exist, no one is waiting on any single result, and the pass over the collection has a clear end. E31 Network is being designed to take exactly this: compute held for the pass, released when it finishes, paid for by the hour.
The shape of an image job
An image processing job declares its work as the model or pipeline: a classifier, a segmentation model, an OCR step followed by a language model, a feature extractor, a chain of several. The data is the image collection, staged for the job. The request is the compute needed and whether the pass has a deadline or simply runs until done. The output is the per-image result, collected into a form the team can use: a file of labels, a set of masks, extracted text, embeddings.
Because the images are independent, the job is almost perfectly divisible. It can run across many GPUs at once and finish quickly, or across fewer for longer. The network is being designed to accept either shape, and the job should say which it prefers. A team that needs the output by a particular point should say so; a team that does not should let the job take whatever slot the scheduler finds, since a job that can wait costs nothing while it waits.
Many small units, one job
The program's list of unsolved problems includes scheduling mixed job sizes fairly: a job that needs eight GPUs for four hours beside one that needs a few minutes. An image pass is often the second kind many times over. Each unit of work is brief, but there are a great many of them.
The design intent is that the team describes the collection as one job, not as a flood of tiny submissions. One job, one queue entry, one request, one output. Within the job the network would spread the work across the compute held for it. How a job of this shape should declare itself so that it is scheduled well alongside long, large jobs is part of what the preview exists to work out, and image processing is a good test of it.
Getting the images there
A collection of small files adds up. Getting large datasets to where the compute is sits first on the program's list of open problems, and image collections raise a version of it that is different from a single large video file: many objects rather than one, with the overhead that implies.
The preview is candid that this is not solved. What the design asks for is that the team knows what it is staging and that staging is a declared step of the job rather than something done by hand before submission. A team with a large image archive and an engineering appetite for this problem is the kind of team the design-partner program describes, though intake is not yet open.
Output and accounting
The output of an image pass is structured and much smaller than the input. It is returned to the submitter when the job finishes. The compute is then released and the hours it was held are accounted for in a record the team can read. Rates are not yet published and will be when access opens; the shape of the cost is hours held, nothing more.
What happens to the staged images after the pass is a retention matter whose specifics are not yet published. A team processing images of people, of documents, or of anything else it would not want to leave behind should ask about that before planning a job, rather than assume an answer.
When image processing is not a batch job
A camera on a line that inspects each part as it passes, a scanner that must reject a bad page in the moment, a phone app that identifies what it is pointed at: these are image processing too, but they must answer now, so they stay on local infrastructure, on the device, or on the customer's own systems. The network is for the archive, not for the line.
The test is the same as for every workload. If the images are arriving and something acts on each one as it arrives, the work stays with you. If the images are sitting in storage and can be processed tonight, they can be a job. Processing a backlog of footage covers the moving-picture version, and /workloads lists the rest.
Questions this raises
- Does each image count as a separate job?
- No. The design intent is that the collection is one job, one queue entry, one request, and one output. Within the job the network would spread the work across the compute held for it.
- Can an image job chain several models?
- The work can be a pipeline: an OCR step followed by a language model, a detector followed by a classifier, a feature extractor feeding a deduplicator. The job declares the chain as the work it runs.
- Are the results small enough to hand back easily?
- Usually. Labels, masks, extracted text, and embeddings are much smaller than the images that produced them. The output is returned to the submitter when the job finishes and the compute is released.
KEEP READING