How to Organize a Restaurant Photo Library by Dish and Channel
A restaurant photo library connects each current menu item to its original capture, reviewed edit, and published channel copies. Its purpose is practical: staff should find the right serving photograph, know which recipe it depicts, and update every affected placement when that recipe changes.
Build the library in storage your team already controls. The folders and ledger below are an editorial workflow, not a DishVivid asset-management feature. DishVivid can help edit and review a single dish image; it does not automatically organize your shared drive, synchronize POS items, or publish to delivery apps.
Separate originals, approved edits, and channel exports
| Tier | Keep here | Working rule |
|---|---|---|
| Originals | Untouched camera files, including the capture format actually used | Keep a backup and avoid overwriting these files. |
| Reviewed edits | A selected edit linked to its original, recipe version, and reviewer | Mark which view is current and retire superseded copies. |
| Channel exports | Files prepared for a specific website, menu slot, or platform | Record actual dimensions, format, weight, and publication status. |
A folder called “Raw” may contain ordinary JPEGs. That label describes untouched files in some teams; it does not make them camera RAW data. Use “Originals” if the distinction would confuse staff.
A small dish-first structure might be:
- Mains / Classic Burger / Originals
- Mains / Classic Burger / Reviewed
- Mains / Classic Burger / Exports / Website
- Mains / Classic Burger / Exports / Delivery
- Archive / Retired Items
Keep the structure shallow enough for staff to use. Test it with someone who needs to locate an image during a menu update.
Create a menu-item ledger
A filename helps search, while the ledger records decisions that do not fit in a filename. Include the item ID used in your menu system, the recipe or portion version, and every current destination.
| Field | Why it matters |
|---|---|
| Item ID and display name | Connects the photograph to the correct ordering entry. |
| Location and service format | Distinguishes dine-in, takeout, and store-specific servings. |
| Original and reviewed filenames | Allows later comparison and a new crop without guessing. |
| Capture date and recipe version | Helps identify outdated garnish, packaging, or portions. |
| Approval owner and date | Shows who checked the actual dish. |
| License and permitted use | Records verified permission for the planned channel and edits. |
| Destination URL or item ID | Makes live placements findable when the image changes. |
| Export dimensions, format, and file weight | Records the actual file, rather than an assumed preset fit. |
| Submission and publication status | Separates prepared, submitted, approved, and live assets. |
Use the photo-rights checklist before reusing commissioned, customer, or platform-provided photographs. Owning the dish or paying for a shoot does not by itself settle every reuse question.
Choose filenames your team can maintain
A useful starting pattern is item ID, readable dish name, capture date or version, and image role. For example, an original could be named “BURGER-014_classic-burger_20261010_original.jpg”; a reviewed square export could be “BURGER-014_classic-burger_web-square_reviewed-v1.jpg”.
These are names to apply in your own file system. DishVivid downloads use a generated export suffix and do not automatically adopt this pattern. Rename the downloaded copy after checking it, keeping the source separately.
Avoid excessive ingredient or staff details in filenames. Put those in the ledger. For a more detailed pattern and worked item lifecycle, use the menu-photo file-naming guide.
Review an edit before adding it to the current set
Open a JPEG, PNG, or WebP up to 20 MB in DishVivid Studio. Manual brightness, contrast, saturation, and crop adjustments run in the browser and need no account. Compare with the original, complete the dish checks, and download the JPEG into your own library.
There is no dedicated manual white-balance, highlights, shadows, sharpening, denoise, or background-removal control. Strong color casts, missed focus, and lost source detail need capture changes or suitable external processing.
Optional AI requires sign-in and available edits. Each generated candidate uses an edit and may alter ingredients, portions, or scene details. Compare it with the original and real serving, reject inaccurate results, and approve an acceptable candidate before export. Saved AI works in an account are a separate product flow; manual downloads are not automatically stored in an account library.
A reviewer should check:
- The piece count, protein portion, garnish, and sides match the active recipe.
- The plate or packaging matches this service format.
- The edit does not exaggerate color, scale, or texture.
- The final crop preserves the information needed for its destination.
- The selected file and reviewer decision are recorded.
The approval checklist gives a repeatable sign-off process. Approval is a human decision, not proof of platform acceptance.
Prepare each destination file separately
DishVivid currently exports JPEG with these choices:
| Editor choice | Output | Library check |
|---|---|---|
| Original | Selected image's dimensions | A JPEG export is not a lossless replacement for the untouched capture. |
| Delivery wide | 1600 × 900, 16:9 | Verify the particular destination and actual file size. |
| Delivery classic | 1500 × 1200, 5:4 | Do not assume this meets a larger storefront-cover requirement. |
| Social square | 1200 × 1200, 1:1 | Preview the actual layout and any service-side crop. |
Use the ratio reference and the checked Uber Eats, DoorDash, and Grubhub guides for source dates and placement differences. These editor presets do not certify compliance.
Use another suitable tool for required PNG/WebP conversion, custom resizing, or compression. Inspect that final file again. Record the destination's own submission and publication states rather than assuming the download has gone live.
Hypothetical burger update
Suppose a restaurant replaces the classic burger's brioche bun with a seeded roll. The team creates a new ordinary serving, photographs it, and keeps that capture with the new recipe version.
The manager reviews a restrained manual edit in Studio, downloads a JPEG, and prepares the necessary website and delivery copies. The ledger identifies every live use of the older bun photo. Each replacement is submitted or published through the relevant system and checked in its customer-facing layout.
The old source and exports move to a retired set with the replacement date. They remain available for historical reference but are no longer labeled current. This example has no measured turnaround time, acceptance rate, or customer result.
Multi-location and seasonal decisions
Share a photograph across locations only when the actual serving, included sides, and service format match. If one store uses different packaging or a local recipe, label that variation and review its own photograph. The multi-location governance guide addresses responsibility and exceptions.
When a seasonal item ends, retire its public placements and mark its files inactive. If it returns, compare the old photograph with the current recipe before restoring it. A recurring name does not prove that the portion and garnish are unchanged.
Common library failures
| Problem | Better handoff |
|---|---|
| Staff send only a reduced chat copy | Transfer the original through a checked file-sharing route and verify its dimensions. Chat behavior varies by app and settings. |
| A square crop overwrites the only original | Save separate exports and keep a backed-up untouched source. |
| Several files all say “final” | Record one current version and the destinations that use it. |
| A retired item reappears in a campaign | Separate current and retired sets and check menu availability before publishing. |
| A reviewed download is assumed live | Track submitted, approved, and published states and verify the final placement. |
Start with one menu item. Locate its original, make a reviewed edit in Studio, save the download in your own library, and record where it is used. Expand only when that handoff works for the people maintaining the menu.