Wine Bottle Image Requirements for Distributors and Importer Teams

Start with the distributor’s current specification

This guide is for alcohol importer operations teams that collect and deliver wine bottle images to distributor item-setup, ecommerce, sales, marketing, and portfolio teams. It covers requirement intake, exact product matching, view selection, technical fields, source masters, recipient derivatives, file naming, metadata, rights, accessibility, submission, rejection handling, vintage rollover, and final QA.

There is no useful universal answer to What dimensions should a distributor bottle image use? Follow the current specification from the named distributor, division, portal, or downstream account. Recipients may request different views, backgrounds, filenames, or derivatives. Ask rather than inventing a standard number.

Keep a flexible approved master and create delivery files for known recipients. The master protects future uses. The derivative satisfies the current request. Both must point to the exact wine, vintage status, package, market, and approval record they represent.

Separate image requirements into four layers

A distributor image request can combine product identity, file production, publishing, and internal control. Classify each requirement before assigning work.

Layer	Who controls it	Examples	Operating response
Product and label identity	Approved product, package, and compliance records	Producer, wine, vintage, volume, front label, back label, importer statement	Verify the photographed package against the exact market item
Recipient delivery specification	Distributor, division, portal, retailer, or marketplace receiving the file	View, dimensions, canvas, background, format, maximum file size, filename	Obtain the current written specification and build a named derivative
Rights and publishing review	Rights holder and responsible publishing team	Permitted audience, channel, territory, credit, expiration, retouching	Record the decision before sharing
Internal operating standard	Importer workflow	Master retention, metadata, owner, status, revision, replacement, archive	Apply consistently across the portfolio

Do not turn a recipient preference into a federal rule or treat an approved label as proof that a crop, format, or transparent edge meets a portal specification.

Open an image requirement record before requesting files

Create one request record for each distributor and delivery purpose. If the same distributor has different requirements for item setup and marketing, create separate output profiles.

Use this control block:

Field	Required entry
Request ID	Stable internal reference
Recipient	Distributor, division, portal, or named downstream account
Market	State, territory, or other defined scope
Purpose	Item setup, ecommerce, sell sheet, catalog, presentation, or campaign
Product scope	Exact wines and market items included
Specification source	Current form, portal instructions, email, or approved recipient document
Recipient contact	Person who can resolve unclear fields
Internal owner	Person accountable for delivery and closure
Due context	Confirmed delivery date or launch gate
Output profile	Named set of technical and naming requirements
Status	Draft, collecting, producing, in review, submitted, accepted, rejected, or closed
Revision	Controlled package revision
Exceptions	Unresolved requirement, missing item, or accepted deviation

Save the specification itself, not only a summary. Record when it was received and which division supplied it. If a portal displays instructions only during upload, preserve an approved internal capture or field map so another operator can reproduce the delivery.

Translate the request into a requirement matrix

Do not send a photographer or designer a forwarded email with several ambiguous bullets. Convert the recipient request into one row per required output.

Requirement	Recipient value	Source master value	Planned output	Verification
View	Front, back, angle, detail, case, or other named view	Available approved views	Exact derivative to create	Visual comparison
Pixel dimensions	Recipient’s required width and height	Master pixel dimensions	Export width and height	File properties
Aspect or canvas	Recipient’s stated ratio or canvas	Flexible source composition	Crop or padded canvas	Template overlay
Background	White, transparent, or another stated treatment	Approved isolated master	Delivery background	Edge and canvas review
File format	Recipient’s accepted format	Master format	Delivery format	Extension and file inspection
File-size limit	Recipient maximum when stated	Master file size	Compressed derivative	File properties
Color handling	Recipient profile or mode when stated	Controlled master profile	Export setting	Metadata inspection
Margin or crop	Recipient spacing rule	Full bottle with working room	Composed derivative	Guide overlay
Shadow or reflection	Allowed, required, or prohibited	Approved source treatment	Delivery treatment	Visual review
Filename	Recipient syntax	Internal asset identity	Final delivery name	Pattern check
Metadata	Required embedded or portal fields	Controlled asset metadata	Export and portal values	Field comparison
Delivery route	Portal, secure link, email, or other method	Approved source location	Submitted package	Confirmation record

Use the recipient’s own terms. If primary image, front, hero, and main might mean different treatments, ask the contact to confirm the intended output. Do not silently map them to one internal asset type.

Match the image to the exact market item

A technically valid file can still show the wrong wine. Link every bottle image to the controlled market item before editing or export.

Verify:

• producer and brand
• wine or cuvée
• vintage or controlled non-vintage status
• country, region, and appellation presentation where visible
• bottle volume and package format
• front and back label configuration
• importer statement and market language
• capsule, closure, neck label, embossing, sticker, and gift package
• importer SKU and recipient item reference
• intended market and distributor

TTB’s wine labeling guidance identifies federal wine-label topics including brand name, class or type, alcohol content, country of origin for imports, name and address, and net contents. Use the approved package and compliance record to review visible label identity. Do not use a prior catalog image as the deciding source when the current package differs.

The TTB Public COLA Registry provides information on approved, expired, surrendered, and revoked COLAs. It can support label review, but the image owner still needs to confirm that the photographed bottle is the current commercial package for the market and item being submitted.

Quarantine a source image when identity is uncertain. Mark the missing evidence and contact the responsible product or compliance owner. Renaming a file does not change the bottle shown inside it.

Ask for the views the recipient will use

Build the shot list from the specification and delivery purpose. Do not produce a complete studio library for a request that needs one front bottle, and do not assume a single front view covers item setup, label review, and marketing.

Common view types include:

• Front bottle: Straight-on product-identification view.
• Back bottle: Back label and market-package view.
• Three-quarter bottle: Angled presentation for designed layouts.
• Front-label detail: Close view when the full bottle cannot make small label content readable.
• Back-label detail: Close view for product or market reference.
• Closure detail: Capsule, cork, screw cap, crown, or another relevant closure.
• Consumer package: Gift box, carton, tube, multi-pack, or other retail presentation.
• Shipping case: Case and label view when operations requests it.
• Group image: Defined set of wines for a catalog, presentation, or campaign.

Treat group images as separate assets and record every included item. Keep lifestyle imagery in another category unless the recipient explicitly accepts it for product identification.

Use GS1 as a reference, not a substitute for recipient instructions

The GS1 Product Image Standard defines image categories, product views, backgrounds, formats, naming, identification, metadata, and delivery attributes for product imagery. It is useful when building an internal image model or interpreting a partner’s request.

Do not claim that every distributor implements the complete GS1 standard. Ask whether the recipient follows GS1 naming, view codes, or image treatments and which profile it expects. When the recipient gives a custom instruction, record that instruction as the delivery requirement rather than combining it with a different standard by intuition.

Use the standard to ask which image category, product face, view, background, clipping treatment, naming elements, metadata, and delivery method apply. A standards-based master can still need a recipient-specific crop, filename, or file-size treatment.

Capture technical requirements without guessing numbers

Write each technical requirement as a named field. Blank means unknown, not unrestricted.

Dimensions, aspect, and canvas

Record pixel width, height, orientation, aspect ratio, canvas, margins, bottle scale, baseline, and centering. Distinguish canvas dimensions from the visible product area. Build an overlay or export template for repeat use and do not copy dimensions from another distributor.

Format, compression, and file size

Record accepted extensions, transparency support, prescribed quality settings, and maximum file size. Verify the finished file and return to the approved master for every new derivative.

Background and transparency

State the required background as a value: transparent, white, another color, or recipient-provided template. Record whether a natural shadow or reflection is allowed.

Inspect transparent edges on light and dark backgrounds for halos, fringes, missing glass, clipped foil, and hard transitions. For solid backgrounds, inspect the canvas and corners and confirm that pale labels remain distinct.

Color and product appearance

Record the recipient’s required color mode or profile. Compare the derivative with the master and controlled reference, checking glass, liquid, paper, foil, and embossing. Do not change product color for effect.

Retain one approved master and named derivatives

The source master should preserve enough detail and working room for future delivery profiles. Do not crop it to the first distributor’s canvas and overwrite the original.

For each derivative, record:

Field	Purpose
Asset ID	Stable internal image reference
Source master ID	Exact approved source used
Market item	Wine, vintage status, volume, package, and market relationship
View	Front, back, angle, detail, package, case, or group
Recipient	Distributor, division, portal, or account
Purpose	Item setup, ecommerce, sales, catalog, or campaign
Output profile	Named technical requirement set
Filename	Exact delivered filename
Rights	Approved audience, channel, territory, credit, and expiry context
Approval	Product, image, rights, and publishing decisions
Status	Draft, approved, current, rejected, superseded, or archived
Replacement	Successor image when one exists
Submission	Package and confirmation record

A derivative is not a new master merely because the distributor accepted it. Keep the relationship visible so a correction to the source package can identify every output that needs replacement.

Define retouching and compositing boundaries

Retouching can clean the capture without changing the product. Write the approved boundary into the image brief.

Routine review may permit dust removal, background cleanup, controlled perspective correction, and color balancing against the sample. Require explicit approval before changing:

• label art or vintage digits
• importer statement or regulatory text
• bottle shape, scale, or color
• liquid color or fill level
• closure, capsule, embossing, or neck label
• permanent stickers or deposit marks
• gift packaging or included components

Keep the untouched capture or original producer file internally. If the only available source is a render or mockup, label its source type and approval state. Do not publish it as production photography without the responsible owner’s decision.

Never build a missing current bottle by pasting new label art onto a prior vintage photograph solely to meet a deadline. If a controlled composite is approved for a limited pre-production use, mark its scope and replacement trigger.

Use filenames and metadata that survive handoff

The internal filename should remain understandable after download. A practical pattern is:

producer-wine-vintage-market-volume-view-revision.ext

A distributor may prescribe another pattern based on GTIN, item code, view, or sequence. Use that exact recipient pattern for the derivative while retaining internal identity in the asset record.

Avoid names such as bottle.jpg, new-front.png, final-v3.tif, or use-this.jpg. Do not make current part of the filename when currentness is controlled by status and can change after download.

Record searchable metadata for producer, brand, wine, vintage status, market, language, volume, item code, view, source, rights, owner, approval, status, revision, output profile, and replacement. Keep embedded metadata and portal fields aligned where the recipient uses both.

The broader guide to organizing wine brand assets for distributors provides a portfolio-level structure for current, superseded, and archived files.

Add useful alternative text for digital use

The image file and its text alternative solve different problems. Include an approved image description when the bottle will appear in a distributor portal, ecommerce page, or another digital interface.

The W3C image accessibility tutorial says text alternatives should communicate the information or function represented by an image and should be chosen for the image’s purpose. A front bottle used for product identification may need the producer, wine, vintage status, package volume, and view. A decorative repeat may need different handling by the publishing team.

Keep alternative text factual and concise. Do not add tasting notes, scores, certifications, or origin claims that the image does not need to communicate. Do not use the filename as the text alternative. Update the description when the depicted product or use changes.

Review rights, claims, and publishing context

Record who supplied the image, who owns it, where it may be used, whether credit is required, which markets and channels are permitted, and whether the permission expires. Receipt of a producer file should enter a rights review, not automatically publish it to every distributor.

Separate these approvals:

• product identity approval
• label and compliance review
• photographic or rendering approval
• retouching approval
• rights and credit approval
• recipient technical approval
• final publishing approval

A product image used for item recognition may have a different context from the same image inside a sales advertisement. TTB explains that federal alcohol advertising provisions can apply to regulated industry members’ digital advertisements on its alcohol beverage advertising page. Have the qualified owner assess the finished use rather than only the source image.

Do not place unverified accolades, certification seals, health language, or promotional badges into the bottle-image file. Keep product photography separate from campaign graphics unless the recipient requests a composite and the responsible reviewers approve it.

Submit one controlled delivery package

Keep the distributor-facing package narrow. Include only the required current files, a manifest when useful, and the approved contact route. Exclude raw captures, layered editing files, rejected versions, internal comments, rights evidence, old vintages, and unrelated assets.

Use a manifest with:

• filename
• market item ID
• producer, wine, and vintage status
• volume and package
• view
• recipient and purpose
• output profile
• revision and status
• source master ID
• notes limited to accepted delivery exceptions

Compare manifest and package counts and open each file outside the editor. After a portal upload, compare the visible result with the submitted file and preserve confirmation.

Do not mark the request accepted because the upload completed. Record recipient acceptance, rejection, or pending review as a separate state.

Resolve image rejections in the source workflow

Treat a rejection as structured data. Record the recipient, file, reason, contact, returned example, required correction, owner, and replacement submission.

Classify the issue:

• wrong wine, vintage, market, or package
• missing required view
• incorrect dimensions, aspect, or canvas
• unsupported format or excessive file size
• wrong background or transparency
• poor crop, margin, scale, or baseline
• illegible label or obscuring reflection
• color or retouching concern
• incorrect filename or metadata
• rights or approval gap
• portal or transfer failure

Correct the controlled source relationship or output profile before making the new derivative. If one rejection exposes a template problem, identify every file generated from that profile and review them. Do not patch a single rejected file while leaving the same defect in the next portfolio batch.

Run a repeatable image delivery workflow

Use this sequence for a new distributor, portfolio addition, or revised specification:

1. Request current instructions. Obtain the named distributor’s image specification, portal fields, examples, contact, and due context.
2. Define product scope. List exact market items, vintages, volumes, formats, and requested views.
3. Build the requirement matrix. Translate dimensions, canvas, format, background, margins, naming, metadata, rights, and delivery into testable fields.
4. Audit available masters. Confirm product identity, source quality, view, rights, and working room for each item.
5. Open exceptions. Flag missing bottles, uncertain vintages, old labels, incomplete rights, or unclear recipient fields.
6. Capture or obtain missing sources. Use the wine bottle shots workflow when new photography is required.
7. Create recipient derivatives. Export from the approved master using the named output profile.
8. Review by responsibility. Product, compliance, brand, rights, technical, and operations owners approve their fields.
9. Run file QA. Inspect identity, appearance, edge quality, properties, filenames, metadata, and package count.
10. Submit the controlled package. Use the approved route and retain exact files, manifest, portal values, and confirmation.
11. Capture recipient results. Record accepted, rejected, and pending files separately.
12. Correct from the source. Update the asset relationship or output profile, regenerate, review, and resubmit.
13. Publish accepted files. Make only the approved set current for the intended audience.
14. Retire predecessors. Remove replaced images from routine recipient access while preserving history internally.

Assign one operations owner to close the complete request. Contributors can approve their parts, but someone must reconcile package scope, missing items, rejections, and acceptance.

Treat vintage and package changes as image change sets

Do not overwrite the prior image when a new vintage or package arrives. Create a successor item and reopen every visual dependency.

Review:

• visible vintage statement
• front and back labels
• importer statement and market language
• bottle shape, volume, glass, and liquid presentation
• capsule, closure, neck label, embossing, and stickers
• gift box or consumer package
• item codes and GTIN relationships
• front, back, angle, detail, case, and group images
• filenames, metadata, alternative text, rights, and output profiles
• distributor portals, tech sheets, sell sheets, catalogs, and presentations

Classify each existing asset as approved to carry forward, replaced, awaiting evidence, or not applicable. Search filenames and metadata for the prior vintage, then inspect the pixels. A newly named file can still show an old label.

Keep both vintages available when both are active for the same market. Identify them precisely rather than calling one old and one new. When the prior image leaves current use, link it to the successor and remove it from default distributor access.

Late in this process, Depletement’s pre-launch workspace for importer operations can help organize current product details, bottle and brand assets, tech sheets, sell sheets, distributor asset access, and vintage updates. The delivery standard remains the same: recipient-specific outputs tied to one approved product and source master.

Complete final wine bottle image QA

Run this checklist against the recipient specification, controlled asset record, submitted package, and uploaded result.

Request and product identity

• Recipient, division, market, purpose, due context, contact, and specification source are recorded.
• Every requirement comes from the current recipient instruction or a named internal rule.
• Producer, brand, wine, vintage status, volume, package, market, and item code match the controlled product record.
• Front label, back label, importer statement, language, closure, capsule, stickers, and gift package are current.
• Uncertain or conflicting product identity is blocked rather than guessed.
• Required front, back, angle, detail, package, case, and group views are accounted for.

Technical output

• Pixel dimensions, aspect, orientation, canvas, crop, scale, baseline, and margins match the recipient profile.
• File format, extension, color handling, transparency, and file size meet the stated specification.
• Background, shadow, reflection, and clipping treatment match the request.
• Transparent edges have been checked on light and dark backgrounds.
• Solid backgrounds and corners are uniform where required.
• The bottle is upright, centered as intended, and shown at natural proportions.
• The label remains legible at the intended display size.
• Glass, liquid, paper, foil, embossing, and closure retain believable detail.
• Color matches the approved master and controlled reference.
• No export artifact, corruption, excessive compression, or unintended metadata remains.

Control, rights, and delivery

• Source master ID, derivative ID, market item, view, recipient, purpose, and output profile are linked.
• Retouching has not changed label art, vintage, regulatory text, package shape, liquid, or permanent features without approval.
• Photographs, renders, mockups, and approved composites are identified accurately.
• Owner, rights, territory, channel, credit, expiration, approval, status, and replacement are recorded.
• Filename follows the recipient’s syntax and remains traceable internally.
• Portal metadata and embedded metadata match the approved asset record where used.
• Alternative text reflects the image’s purpose and exact product.
• The delivery package excludes raw files, drafts, internal notes, restricted evidence, and superseded assets.
• Manifest item count matches the delivered files.
• Every file opens outside the editing application.
• Uploaded previews and processed images match the submitted files.
• Submission confirmation, recipient result, rejection reason, and accepted exception are preserved.

Currentness and replacement

• Accepted files are current only for their approved recipient, market, purpose, and item relationships.
• Rejected files are excluded from normal distributor access.
• Corrections were made in the source record or output profile and regenerated.
• Prior vintages and packages remain available only where intentionally active.
• Superseded derivatives point to replacements and no longer compete in current collections.
• Group images were reopened when any included bottle changed.
• Tech sheets, sell sheets, catalogs, presentations, and portal pages using replaced images were reviewed.
• A second reviewer can trace the accepted distributor image to the requirement, market item, source master, approvals, and submission.

A reliable distributor image package is not defined by one preferred dimension or background. It is defined by an exact product match, a current recipient specification, a controlled source master, a reproducible derivative, and evidence that the recipient accepted the result.