Attribution and Image Credit Records

What an Image Credit Register Does for Exhibition Boards

An Image Credit Register is a working project record for visual assets appearing in concept previews, campaign boards, presentation decks, screen mockups, and proposed exhibition graphics.

It should answer four practical questions:

1. Which image is being discussed?
2. Who created it, and where did it come from?
3. What license or permission information has been recorded?
4. Which questions remain unresolved at this review stage?

The format may be a spreadsheet, digital asset management system, shared project document, or another traceable method. The format matters less than the connection between the image on the board and the record assigned to it.

A useful entry may include:

• Asset identifier and board, page, or zone reference
• Creator, rights holder, work title, and original source
• Credit Line, Source, copyright notice, and license information
• Permission contact and intended usage context
• Modification status and evidence date
• Current review status, open question, and responsible owner

This is a practical workflow schema, not a mandatory legal or industry form. The project may need fewer or additional fields depending on the asset, source, venue context, and intended use.

The first checkpoint is simple: can another project participant identify the image on the board and find its corresponding record without guessing?

Start With the Visitor View

The visitor view identifies what the image is doing in the exhibition concept. A large photograph may establish the focal point from the aisle, support a product message at the zone threshold, or sit behind a screen near a meeting area.

That role affects the record because the same asset may appear as:

• A full-bleed printed wall graphic
• A cropped image beside a headline
• A background behind a screen
• A detail image in a product panel
• A temporary reference in an internal preview
• A campaign image proposed for later production

The record should identify the intended use rather than merely naming the file. “image-07.jpg” gives little handoff value. “North wall hero image, visitor approach view, concept board version 03” connects the asset to a visible project decision.

The image shows the proposed placement. The register records what is known about the asset.

Record the Board Location

A source record is easier to examine when it includes the image’s location within the concept.

• Board name or file name
• Page number and booth zone
• Wall, screen, counter, or meeting surface
• Visitor approach angle
• Crop, orientation, and concept version
• Date added and person who added the image

This prevents a common handoff problem: a source record exists, but nobody knows which of several similar images it describes. If the same image appears in multiple zones, record each proposed use or connect those uses to a shared asset identifier.

Keep Credit Line and Source Separate

Credit Line and Source are related, but they do different work. IPTC guidance describes the Credit Line as wording used to credit an image when published. It may contain an agency name, photographer name, or rights statement supplied by the image provider.

The Source field identifies a party in the supply chain. That may be an agency, originating organization, or photographer. The original creator and immediate supplier may therefore need separate entries.

Combining these fields into one free-text note can hide important differences. A credit line may explain how recognition should appear. It does not, by itself, establish the complete usage context or permission position.

The board needs a visible credit treatment. The register needs a traceable source and rights record. Keep those decisions connected, but separate.

Image Credit Record Fields That Carry the Most Weight

Not every field deserves the same attention at every stage. Identification, source status, rights conditions, intended use, and unresolved ownership questions usually carry the central handoff value.

Asset Identifier

Assign a stable identifier that stays with the image across board versions and exports. It should not depend only on a changing file name, because an image may be renamed, cropped, compressed, or replaced while the board reference remains active.

Creator and Rights Holder

Record the creator name as supplied by the source. Where the rights holder differs, record that distinction rather than assuming the two are identical.

The U.S. Copyright Office explains that ownership of a physical copy of a photograph is distinct from ownership of the photographic work. Its guidance also notes that ownership can be difficult to determine from an individual copy.

“Creator unknown” or “rights holder unknown” is more useful than an invented answer. The unknown status should lead to a named follow-up question.

Work Title and Original Source

Record the work title when the source supplies one. If no title is available, state that clearly rather than substituting the hosting website’s name.

Also record where the image was obtained or where the original work record can be found. A platform page, repost, search result, or screenshot may help locate an image, but it does not automatically establish that the uploader controls all relevant rights.

Exact License or Rights Basis

“Creative Commons” is not a complete license identification. The specific designation and version matter because different licenses contain different conditions.

Creative Commons materials describe elements including Attribution, NonCommercial, NoDerivatives, and ShareAlike. Preserve the exact designation shown by the source rather than reducing it to a general label.

For other assets, the record might state:

• Written permission
• Supplier license
• Commission agreement
• Public-domain statement
• Internal asset ownership record
• Rights status unknown or pending confirmation

These labels describe the current record. They do not settle a project-specific rights question.

Evidence Date and Intended Use

Store the date on which the source or license information was checked. Rights pages, platform labels, and source descriptions can change, while the date makes the review history visible.

Describe the proposed use in project language, such as internal concept review, exhibition wall graphic, printed handout, on-site screen, event promotion, website, or supplier production file.

A record may address one use and leave another open. “Project use” is too broad to replace the actual context under review.

Modification Status

Record whether the image is unmodified, cropped, resized, color-adjusted, combined with text or graphics, or edited in another way. Also note when an earlier modification is attributed to an unknown party.

Creative Commons attribution guidance recommends indicating when material has been modified. The field describes what happened to the file; it does not determine whether the proposed modification is permitted.

Creative Commons Attribution in a Concept Workflow

Creative Commons materials provide a useful structure for attribution records. A practical model captures the title, creator, source, specific license, license location, modification note, and proposed visible credit.

Attribution should not imply that the licensor endorses the user or the use. That question can matter when a branded exhibition concept places an image beside a company message.

A concise credit line may suit the board, while the full register retains the longer source, license, and modification information.

Why the General Label Is Incomplete

Creative Commons identifies a family of licenses and related tools. Their conditions are not interchangeable.

• Which specific license applies?
• Is the proposed commercial context addressed?
• Are modifications addressed?
• Is attribution required in a particular form?
• Is the source record current?
• Was the license applied by the creator or by another party?

Preserve the exact designation shown by the source. The source record should also be checked because a platform label does not independently verify every rights detail.

Attribution Is Not Permission

Credit and permission belong in the same review conversation, but they are not the same record. Attribution identifies creator, source, and credit information. Permission or licensing information addresses the proposed use and its conditions.

A credit line can be present while the usage question remains unresolved. Track the image, source, rights basis, conditions, intended use, and open question as separate review points.

Metadata and Visible Credits Are Different Layers

IPTC photo metadata can carry creator, source, credit, copyright, and licensing information. It can support retrieval and handoff when a file moves between designers, reviewers, suppliers, and archive locations.

The metadata record and the printed or displayed credit remain different layers. Information stored only in metadata may not be visible to people who encounter the image elsewhere, and ordinary file handling may remove or change embedded fields.

For an exhibition board, examine both:

• What information is embedded in the asset or stored in the register?
• Where, if anywhere, will the visitor-facing credit appear?

The preview can show a proposed placement. It does not establish that metadata will remain intact in the final production file. The supplier or production team may need to confirm how source information travels through export, layout, print, screen, or archive workflows.

When Records Disagree

Record the conflict rather than silently choosing one version.

• The embedded creator field differs from the source page.
• The Credit Line names a supplier while the Source field names an agency.
• The source page shows one license while the exported file retains an older rights note.
• The title is absent from the file but present on the original record.
• The crop removes contextual information that appeared beside the source image.

Use a status such as “conflict requires review” and assign the question to the person responsible for source verification, rights review, or project handoff.

From Concept Preview to Production Handoff

The register becomes more useful when it follows the project’s review stages. Each stage adds a different kind of information without collapsing a visual proposal into a rights determination.

1. Identify the asset on the board.

   Assign an identifier and record the board version, zone, intended use, and whether the image is a temporary reference or proposed production asset.

2. Connect the asset to a source record.

   Locate the original source, supplier record, or internal asset reference. If the source cannot be identified, mark the asset unresolved rather than replacing the unknown source with a platform name.

3. Capture creator, title, credit, and source fields.

   Populate each field using information supplied by the source. Record “not supplied” or “unknown” when information is absent.

4. Record the rights basis and conditions.

   Enter the exact license, permission description, contract reference, or unresolved status. Preserve the intended exhibition context.

5. Compare the proposed use with the record.

   Review the placement, crop, combination with a brand message, and public-facing context. An internal concept discussion and an exhibition wall graphic are separate uses to examine.

6. Record modifications and visible credit treatment.

   Document crops, edits, overlays, and color changes. Then compare the proposed credit wording and location with the source record.

7. Mark review status.

   Useful statuses include Identified, Source recorded, License recorded, Permission evidence received, Credit treatment proposed, Needs rights review, Needs source clarification, Needs supplier confirmation, and Ready for handoff review.

8. Transfer the record with the handoff package.

   Carry the register reference with the concept files, image assets, and production notes. Open questions should travel with the asset rather than remain in a separate conversation.

“Ready for handoff review” describes a workflow state. “Approved” may imply a determination that this register cannot make by itself.

A Worked Example: One Image, Three Review States

Consider an invented example: a concept board places a photograph across the back wall behind a product message. The image is visually convincing from the aisle approach angle, but its source status changes during review.

Concept Preview

The board identifies the asset as BW-HERO-04 and marks it as a temporary reference.

• Proposed location: back wall
• Visitor view: main aisle approach
• Intended role: primary background image
• Source, credit, and license: unknown
• Status: concept reference only

The image can support a layout conversation. It cannot support a conclusion about later use.

Source Review

The team finds a source record with a creator name, work title, and specific Creative Commons designation. The register adds the original source, license location, evidence date, crop status, and proposed exhibition use.

The record is now more useful, but the proposed context and visible credit treatment still require project review.

Handoff Review

The designer exports a production reference with the crop and proposed credit placement. The supplier receives the image file and register entry.

The remaining questions are precise:

• Does the recorded rights basis address the intended exhibition use?
• Does the credit line match the source instructions?
• Will the credit remain visible in the final format?
• Does the supplier have the same asset version as the register?
• Has any source information changed since the evidence date?

The concept preview does not answer these questions. It helps route them to the responsible project roles.

Common Mix-Ups

A Credit Line Is Treated as a License

A credit line tells the team how recognition may be displayed. It does not necessarily identify every usage condition. Keep it beside the license or permission field, not in place of it.

The Platform Is Treated as the Creator

A hosting platform may provide access to an image without being its creator. Record the creator named by the source, then record the platform or supplier separately.

Metadata Is Treated as a Permanent Record

Embedded fields can support retrieval, but they may be edited or lost during file handling. Keep the register and source evidence alongside the asset.

A Watermark Is Treated as a Rights Signal

The presence or absence of a watermark may help identify an image or supplier. It does not settle the usage question.

A Search Result Is Treated as the Original Source

A search result can lead to a source record. It is not necessarily the original work page or rights record. Record the original location when it can be identified, and mark the source unresolved when it cannot.

A Concept Preview Is Treated as Production Evidence

A board demonstrates a visual proposal from a particular approach angle. It does not establish final dimensions, file suitability, venue acceptance, accessibility arrangements, structural conditions, or production readiness.

How to Judge the Register at Each Review Stage

A useful register can be examined through four separate lenses:

• Identification: Can the team match the image on the board to one record and one asset version?
• Attribution: Does the record preserve the creator, title, source, Credit Line, and other information supplied by the source?
• Rights and conditions: Does it identify the exact license or permission basis and intended use context?
• Handoff: Can the next role see the asset, source evidence, proposed credit treatment, modification status, and unresolved questions?

Missing information should remain visibly missing. A record that answers the first three lenses may still fail at handoff if its details are disconnected from the correct board version or production file.

Questions for the Handoff Roles

Designer

• Which asset identifier appears in each board or zone?
• Is the image a temporary reference or a proposed final asset?
• What crop, overlay, or modification does the concept show?
• Where is the visible credit placed?
• Does the proposed treatment remain readable from the intended visitor view?

Supplier

• Which image file and version were received?
• Does the production reference match the register entry?
• How will the Credit Line travel with the production files?
• Which source information will remain available after export?
• Which file or format questions remain open?

Organizer

• Does the event or venue provide instructions relevant to displayed image credits?
• Are there submission or display requirements affecting the proposed treatment?
• Which review process applies to the finished graphic?

Rights Holder or Qualified Adviser

• Does the recorded rights basis address the proposed exhibition use?
• Are the intended modifications addressed?
• Are additional rights or permissions relevant to the planned display?
• Is the source information sufficient for the current jurisdiction and use?

The register prepares these questions. It does not answer project-specific rights questions.

Compact Image Credit Register Template

A longer record is not automatically better. The team should be able to tell which values are confirmed, supplied, inferred, or unresolved during a live project review.

Final Review: What the Record Lets the Team Decide

Before an image moves from concept review toward production discussion, distinguish these five layers:

1. A convincing visual proposal
2. An identified image and source
3. A recorded credit line and metadata set
4. A stated license or permission record
5. A project review or approval handled by the responsible role

These layers should not be collapsed into one status. The image shows how a visitor may encounter the asset. The source record confirms what information has been gathered. The register identifies what changed, what was checked, and what remains unknown.

That separation gives the designer, supplier, organizer, rights holder, or qualified adviser a clearer handoff. Track the image before you reuse it, and carry its source status, license conditions, credit treatment, and unresolved questions with the exhibition concept.