Images and hand copies
A tablet in DAPCA can carry hand copies, photographs, RTI renderings and folio scans. What you upload is not, however, what gets stored: the platform rescales, re-encodes and renames every file it receives. This page states exactly what it does — so that you can prepare material in the knowledge of what will survive the process — and then proposes a way of preparing hand copies.
Uploading requires an editorial account.
1. What the system does to your file
These are not recommendations; they are what the code does with every image.
| Step | Behaviour |
|---|---|
| Accepted formats | JPEG only — .jpg, .jpeg, .jpe, .jfif. PNG and TIFF are refused at upload |
| File name | replaced by a randomly generated identifier. The name you uploaded survives only as a field on the record |
| Location | static/img/tablets/, flat: no per-tablet folders |
| Downscaling | the image is fitted inside 2500 × 2500 px, aspect ratio preserved, and only if it is larger. The file is re-encoded in the process |
| Thumbnails | two are produced: a 300 px file on disk beside the original, and a 300 px copy at quality 50 stored in the database — the latter is what every preview in the interface uses |
| Deletion | removes the image and its thumbnail file |
Categories recorded on the upload form:
- Type — Handcopy, Picture, Seal, RTI, Folio.
- Face — complete, obverse, reverse, top, bottom, left, right, fragments, unknown.
What follows from this
- There is no point in uploading a 300 MB TIFF. It will be refused; and even a very large JPEG has everything above 2500 px discarded, then is re-encoded. Preservation of high-resolution masters is a separate concern and belongs outside the platform.
- The file name is not an identifier. The association between an image and a tablet is made by the record, not by the name. Naming your files carefully is still worth doing — for your own archive, and because the original name is preserved on the record.
- Preview quality is fixed. Every thumbnail is generated at quality 50 from a 300 px reduction. An image with weak contrast will be illegible in the previews however good the full-size file is. Contrast, not resolution, is what buys legibility at that size.
Seal images follow a different path
Images uploaded from a seal record are stored without any downscaling and with no thumbnail file: only the database preview is generated. A 6000 px file uploaded there stays 6000 px on disk.
Until this is aligned with the tablet pipeline, resize seal images yourself before uploading them.
2. Preparing a hand copy
Recommendations, not project policy
What follows is a workflow derived from the technical constraints above and from ordinary imaging practice. It is not an established project standard. Where your own practice differs and works, keep it.
The aim is a legible, square-on, high-contrast image whose long side is around 2500 px — that is, an image the platform will store as you prepared it rather than as its own resizing algorithm decides.
2.1 Acquisition
Scan rather than photograph whenever the copy is ink on paper. 600 dpi, greyscale is ample for a hand copy: the drawing has no colour information, and greyscale keeps the stroke edges that a bitonal scan would destroy.
Photograph only when scanning is impossible — a copy in a bound volume, an oversize sheet. In that case shoot square-on, with even lighting and no flash, and develop the raw file before anything else.
2.2 Straighten and crop
Rotate until the lines of the drawing are square to the frame, then crop away everything that is not the copy. This matters more than it seems: the platform scales the whole frame down to 2500 px, so every centimetre of margin is resolution spent on nothing.
2.3 Clean the background
Bring the paper to white and the strokes to black — levels or curves, not brightness. A clean, high-contrast copy at 1500 px is more legible, at every size the interface uses, than a grey one at 4000 px.
Resist the temptation to retouch the drawing itself. Cleaning the background is presentation; redrawing a stroke is an editorial claim, and if you make it, say so in the record's notes.
2.4 Resize deliberately, then convert
Resize the long side to 2500 px yourself, with a resampling filter of your choice, and save as JPEG at quality 90–95. Doing it before upload means you control the reduction instead of inheriting it, and the platform will then leave the image alone.
2.5 Upscaling — when, and with what caveat
A copy scanned from a printed reproduction, or a legacy image that is simply too small, can be reconstructed with a neural upscaler such as Upscayl.
Upscaling invents detail
On a hand copy, detail is the sign. An upscaler produces plausible strokes, not documented ones: it can turn an ambiguous wedge into a confident one that no copyist ever drew.
Use it for legibility, never as the basis for a collation, and record in the image's notes that the reproduction has been upscaled. A reader who does not know cannot discount it.
2.6 Tools
All open source, all cross-platform.
| Tool | Use it for |
|---|---|
| GIMP | rotation, cropping, levels and curves, manual cleaning |
| ImageMagick | conversion and resizing in bulk, from the command line |
| ScanTailor Advanced | deskewing and background normalisation over a series of scans |
| Upscayl | neural upscaling of reproductions that are too small |
| darktable | developing raw files when you started from a photograph |
Three ImageMagick commands that cover most of the work:
# Resize the long side to 2500 px and save as high-quality JPEG
magick input.tif -resize 2500x2500\> -quality 92 output.jpg
# Same, over a whole folder, writing into ./out
mkdir -p out
magick mogrify -path out -format jpg -resize 2500x2500\> -quality 92 *.tif
# Greyscale + normalise the background of a scanned copy, then resize
magick input.jpg -colorspace Gray -normalize -resize 2500x2500\> -quality 92 output.jpg
The > at the end of the geometry is what makes the operation downscale only: an image
already smaller than the box is left untouched rather than enlarged.
3. Uploading
Images are uploaded from the administrative interface, in its image section; a tablet's record links straight to the upload form for that tablet. Seal images are uploaded from the seal record instead — see Seal catalogue.
The fields are not bookkeeping: they drive how the image is presented.
| Field | Why it matters |
|---|---|
| Tablet | the record the image belongs to |
| Type and Face | govern the order in which images appear on the tablet page and, for seals, whether they are shown at all |
| Caption | the label the reader sees |
| Bibliography and pages | the provenance of the reproduction — indispensable for a published hand copy |
| Notes | where to declare any manipulation: upscaling, heavy cleaning, a composite of several shots |
Image visibility is not uniform
On a seal, only images of the complete face are shown to every authenticated user; the other faces require permission for seals. Plan which face you assign accordingly.
How the images then appear to a reader — the viewer, the thumbnail strip, the lightbox — is described in View tablet.