How to Build Camera Test Packages with Exposure and Color Charts

A camera test package earns its keep when post can answer four questions from it without calling anyone. How should this camera be exposed? How does it behave under the show’s lighting? How does it map into the color pipeline? How does it compare with the other cameras on the job? That takes more than a ColorChecker held in front of the lens for five seconds. You need a repeatable shooting method, documented camera settings, and clean chart frames. You also need lighting notes, post analysis, and a library structure future productions can search. For one camera on one shoot, the package can stay lean. For multiple brands, multiple sensors, or a show that will return for another season, treat the package as a technical deliverable.

Start with the decision the test is meant to support

A camera test drifts fast. One person wants to test skin, another wants to compare lenses, a third wants a LUT. The colorist wants chart frames. Editorial wants camera names and timecode that make sense. The DIT wants to know whether the dailies transform is safe. So define the decision first. Common decisions include:

Matching crash cams, drones, mirrorless bodies, action cameras, or phones to a cinema camera
Establishing exposure guidance for a DP and camera team
Building or validating a show LUT
Testing an ACES, LogC, S-Log, V-Log, REDWideGamutRGB, DaVinci Wide Gamut, or camera-managed pipeline
Confirming that dailies, editorial proxies, and finishing media carry the right color metadata

The chart package should serve that decision. If the question is “Can this B camera cut with Camera A in mixed office lighting?”, a perfectly isolated lab chart under one daylight source won't tell the whole story. If the question is “Can we build a technical input transform?”, then casual chart frames from the end of a lighting test aren't good enough. ACES guidance is direct on this point. Chart capture for transform generation is a precise procedure, and a poorly generated transform can be worse than no transform. Not every production needs a formal IDT session. Every production does need to separate quick creative camera tests from calibration-style chart capture.

Choose charts based on the job, not brand loyalty

X-Rite and DSC Labs charts solve different problems. Many productions carry both.

Compact color charts and larger video charts answer different test questions.

Chart or reference	Best use	Main strength	Watch out for
18 percent gray card	Exposure placement and white balance reference	Fast, simple, easy to repeat across cameras	Does not describe color rendition or highlight behavior
X-Rite ColorChecker Classic or Passport	General color reference, quick comparisons, travel kits	Widely recognized and easy to shoot on set	Small patches can be hard to sample if the chart is too small in frame
X-Rite ColorChecker Video	Video-oriented color and skin reference	Familiar to DITs, editors, and colorists in fast workflows	Still needs controlled lighting and proper transform handling
DSC Labs ChromaDuMonde, OneShot, or CamAlign	Scope-based camera matching and engineering review	Designed for vectorscope, grayscale, and camera alignment work	Larger, more expensive, and less casual to deploy
Grayscale or step wedge chart	Tonal response, clipping, shadow separation, latitude checks	Shows how exposure maps through the camera and transform	Must be evenly lit and exposed carefully to be meaningful
Focus or resolution chart	Sharpness, lens behavior, debayer, detail, or compression testing	Separates optical and processing issues from color issues	Can distract from exposure and color goals if the test is not scoped
Gray ball, chrome ball, and color chart	VFX lighting reference and CG look development	Helps reconstruct lighting direction, intensity, and color	Needs VFX supervision and consistent placement to be useful

The familiar X-Rite ColorChecker Classic, ColorChecker Passport, and ColorChecker Video charts are compact and affordable. DITs, colorists, and editors understand them, and so does finishing. They work for white balance reference, relative exposure checks, and rough camera-to-camera comparison. They also travel well and shoot fast at the head of a setup. DSC Labs charts are more production-oriented for video workflows. ChromaDuMonde, OneShot, and CamAlign are built to be read on scopes and used in engineering-style camera matching. The grayscale and dynamic range charts serve the same purpose. They are larger and more expensive. In exchange you get clearer vectorscope placement, skin tone behavior, and grayscale tracking. Exposure response reads with less ambiguity too. A practical test package usually includes a few chart types:

18 percent gray card for exposure and white balance reference
Color rendition chart such as X-Rite ColorChecker Classic, Passport, or Video
DSC Labs color chart when scope-based camera matching is part of the workflow
Grayscale or step wedge chart for tonal response and clipping behavior
Focus or resolution chart if sharpness, lens behavior, or debayer/detail settings are part of the decision
Gray ball, chrome ball, and color chart if VFX, lighting reconstruction, or CG look development is involved

The takeaway is simple. A ColorChecker alone isn't a full camera test, though it is a useful reference target. For exposure latitude, you need tonal steps. For camera matching, you want charts that read clearly on scopes. For VFX, you need lighting references. For actual profiling, you need chart layout data, reference values, controlled lighting, and enough care that the measured patches mean something. Don't assume a chart can “fix” color by itself. Color rendition charts aren't magic calibration devices unless you have the right reference data and a controlled process. Use them to anchor decisions, compare cameras, and document conditions. Be careful with one-click correction if you don't understand what transform it's building.

Build a controlled setup that production can repeat

The goal is repeatability. You want a package where Camera A, Camera B, and Camera C were tested under the same conditions, with settings that reflect the real shoot. For a controlled chart setup, keep these variables stable:

Light source and color temperature
Light level at the chart
Camera distance and framing
Lens focal length or field of view
Aperture, shutter, ISO or EI, frame rate, and recording format
White balance method and Kelvin value
Monitoring transform and any LUT used on set
Timecode, slate naming, and camera ID
Chart angle, chart flatness, and glare control

The unglamorous details decide the result. Uneven lighting, a chart that isn't flat, or specular reflections can ruin a test. So can a wrong focus plane, in-camera processing, or a chart that's too small in frame. Those failures are easy to miss on set because the image “looks fine” on a monitor. They show up later as noisy patch readings, inconsistent grayscale, or false conclusions about a camera. Light the chart evenly. Avoid reflections. Keep the chart perpendicular to the lens unless you're intentionally testing angle or flare. Use a lens and distance that avoid distortion across the chart. Fill enough of the frame to sample patches cleanly, and leave enough border to confirm the chart isn't cropped or distorted.

An even, front-on setup keeps chart captures repeatable.

For mixed-camera testing, standardize motion settings first. Frame rate and shutter angle affect motion blur in ways post can't cleanly repair. Manual Kelvin white balance is usually safer than auto white balance, especially on multicam interviews, events, and documentary work where angles need to cut together. If one camera drifts in auto white balance while the others are locked, the chart frames won't save the edit.

Capture the camera settings like metadata depends on it

The chart package is only useful if post knows what it's looking at. A chart frame without camera settings is a nice picture of a chart. For each camera body and setup, record the core technical state:

Camera make, model, serial number, and firmware
Sensor mode, resolution, crop mode, and aspect ratio
Codec, bit depth, chroma subsampling, compression ratio, and RAW settings
Log or gamma curve, color gamut, and camera color science version if applicable
ISO, EI, gain mode, or dual-base setting
Shutter angle or shutter speed
Frame rate and project base rate
White balance Kelvin and tint or CC value
Lens make, focal length, T-stop, filtration, and any speed booster or adapter
Internal noise reduction, sharpening, detail, highlight recovery, or look settings
Monitoring LUT, show LUT, CDL, or viewing transform
Audio sample rate and timecode mode when relevant to editorial sync

This belongs in the camera report and in the test package notes, and your slates should show it where possible. A production's workflow memo should already capture camera choice, resolution, and framing. It should also cover frame rate, data management, and color management, plus the dailies deliverables. The camera test package feeds that memo. When editorial will receive proxies, include how chart shots should transform into dailies. Dailies are technical, color-corrected, properly framed versions of the day’s clips that bridge set and post. If the chart package establishes the wrong transform, that error propagates through dailies and offline editorial, then into review files and finishing references.

Shoot exposure brackets instead of a single “correct” frame

One properly exposed chart frame is useful. A bracketed series is far more useful.

Exposure brackets show how each camera behaves above and below normal.

Exposure brackets show where the camera places middle gray, how it rolls into highlights, and how shadows behave. They also show how much correction is comfortable before the image breaks. That matters most when comparing cameras with different log curves and RAW controls, or different highlight handling and noise behavior. A simple bracket pattern might include:

Normal exposure based on the chosen meter method
One stop under and one stop over
Two stops under and two stops over
Additional half-stop or third-stop increments near expected clipping points
A gray card frame at each key exposure when transform work is involved
A skin tone reference at normal, under, and over exposure if talent is available

The exact bracket range depends on the camera and the decision. For cinema cameras, you may want a wide range to evaluate highlight retention and shadow noise. For small cameras or phones, you may care more about when sharpening, tone mapping, and noise reduction become obvious. For HDR delivery, you need to know what happens in bright practicals, windows, and speculars, not only in chart whites. When shooting brackets, don't change multiple variables at once. Adjust exposure in a controlled way, and document which variable you moved:

Aperture, which also changes lens performance and depth of field
Shutter, which changes motion
ISO or EI, which may change noise behavior or highlight allocation depending on the camera
ND or light level, neither of which changes depth of field or motion

For chart-only exposure response, light level or aperture changes are the easiest to interpret. Your method should still match the real production question.

Include real-world lighting after the clean chart pass

A clean chart pass is the baseline. It isn't the whole test. After the controlled chart frames, shoot the situations the production will actually face. Sodium-vapor street spill, LED volume light, and mixed office fluorescents are common. So are tungsten practicals, firelight, and stage color. Car interiors, overcast day exteriors, and high-contrast windows round out the list. For each lighting condition, capture:

Gray card
Color chart
Skin tone reference when possible
Neutral wardrobe or fabric
Important production colors, such as hero wardrobe, product colors, set paint, screens, or brand colors
A few seconds of motion if the test affects editorial matching

This is where camera differences become obvious. Some cameras match well under daylight and separate badly under narrow-spectrum LEDs. Some hold skin beautifully but push saturated blues or reds. Some small cameras look acceptable until mixed lighting triggers aggressive noise reduction or local tone mapping. Don't overbuild this into a full shoot day unless the production needs it. The value comes from controlled comparison: same subject, same lighting, same framing, same exposure method, same transform path.

Keep the slate and naming predictable

Camera tests fail in post when the media is technically fine but impossible to interpret. “A001_C003” isn't enough when there are eight cameras and twenty brackets. Use visible slates and folder names that describe the test. Good labels carry camera ID, chart type, and lighting condition. Add exposure offset, color pipeline, and date. A useful naming pattern might look like this:

CAM_A_ALEXA35_DAY5600_COLORCHECKER_NORMAL
CAM_A_ALEXA35_DAY5600_COLORCHECKER_PLUS1
CAM_B_FX6_DAY5600_COLORCHECKER_NORMAL
CAM_B_FX6_DAY5600_COLORCHECKER_PLUS1
CAM_C_BMPCC6K_TUNG3200_DSC_ONESHOT_MINUS1

The exact syntax matters less than consistency. It works when the camera department, the DIT, and the assistant editor can all decode it without a phone call. The colorist should be able to as well. For multicam tests, assign permanent camera IDs early. Camera A shouldn't become Camera C halfway through the test because someone liked a different body more. Editorial and post supervisors need continuity of identifiers across camera reports and folder names, and across proxies, timelines, and color notes.

Analyze the footage in the same pipeline the show will use

Don't judge log chart frames by eye in a random viewer. Bring the footage into the color pipeline the production expects to use.

Chart footage should be reviewed through the intended color pipeline.

If the show is using ACES, test through the intended input transforms and output transform. If the show is using a manufacturer pipeline, test the manufacturer transform and show LUT. If the colorist will work in DaVinci Wide Gamut or another managed space, test that path. When dailies will use CDLs plus a show LUT, include that dailies path in the analysis. Your analysis should answer practical questions:

Does middle gray fall where expected after the transform?
Do neutral patches stay neutral, or is there a tint bias?
Does skin sit where the DP and colorist expect after the base transform?
How far can each camera be pushed before noise, banding, clipping, or hue shifts become unacceptable?
Which settings should the team ban because they create avoidable post problems?

Use scopes, not only monitors. Waveform shows exposure placement, clipping, and grayscale separation. RGB parade shows channel imbalance. Vectorscope compares hue and saturation behavior. False color can be useful when it's aligned with the camera’s log curve or the working color space. For exposure charts or step wedges, look for where patches merge at the top and bottom. If a step chart uses small increments, the waveform reveals where the camera stops separating tones. Visual inspection still matters, because noise texture, compression, and sharpening may be more objectionable than the numeric clipping point. Color breakup can be too. When matching cameras, avoid the trap of forcing every patch to line up perfectly. Different cameras have different spectral sensitivities, matrices, and tone mapping. A correction that makes chart patches match can make skin or real objects look worse. Use charts to guide the match, then confirm on faces, wardrobe, and production design. Do that under the practical lighting the show will use.

Turn findings into production guidance

Your test package should produce decisions. A useful summary for production might say:

Camera B should be rated one-third stop lower than Camera A for the show look.
Camera C is acceptable for daylight inserts but not mixed LED interiors.
The show LUT is safe for dailies, but the dailies team should apply only primary CDLs.
Your team shouldn't use auto white balance, internal sharpening above a certain setting, or high-compression proxy recording.
Editorial should flag the drone camera in editorial bins because it needs a separate transform.

Keep the language direct. Editors and post supervisors need to know which camera is which, which transform the team used, and whether the material is expected to cut. Include the caveats too. Your notes should say whether the test used a single lens and a single firmware version, and whether it covered one lighting source and one recording format. If production later swaps to a different sensor mode or bakes in a different LUT, the reference may no longer apply.

Package the reference library so future teams can use it

A camera test is expensive. Don't let it disappear after the prep week. Create a reference library that keeps original media and proxies together with stills, notes, and analysis. The structure should be simple enough that an assistant editor can ingest it and a colorist can find the original chart frame two years later. A practical library structure could include:

Camera_Test_Package/
  00_ReadMe/
  01_Workflow_Notes/
  02_Original_Camera_Media/
  03_Transcodes_Proxies/
  04_Reference_Stills/
  05_LUTs_CDLs_Transforms/
  06_Scope_Exports_Reports/
  07_Colorist_Notes/
  08_Editorial_Notes/

The readme isn't optional. It should explain the shoot date, crew, and cameras. It should also list the chart types and lighting setup, the pipeline assumptions, and any known limitations. Include chart serial numbers or target versions when available, especially for formal profiling work. Some profiling workflows depend on chart layout files and measured reference values. Targets can vary in manufacturing and can fade or get damaged, so document which physical chart the team used. For each camera, store:

Original camera files
Camera reports and lens notes
Stills exported through the neutral technical transform
Stills exported through the show look, if one exists
CDL and LUT versions your team used during analysis
Resolve project, Baselight scene, or other grading project when allowed
Written conclusions and exposure recommendations

Don't store only graded JPEGs. Future teams may need to reprocess the test through a new ACES version, a new manufacturer transform, or a different HDR output. Keep the OCN or original test clips with enough metadata to rebuild the analysis.

Treat chart condition and environment as part of the data

Charts are physical objects. They pick up fingerprints, scratches, and dust. They also warp, fade in the sun, and catch coffee mist. A damaged chart can make a camera look wrong. Store charts in protective cases. Avoid touching patches. Keep them out of direct sun except when shooting. Replace charts that are visibly faded or damaged. For measurement-heavy work, use charts with measured reference data, or take a separate chart measurement. The same applies to the viewing environment. If analysis happens on an uncalibrated display in a bright room, conclusions about subtle color differences are shaky. You can still learn useful things from scopes and relative comparisons, and you should be honest about the limits. A reference-grade review environment isn't always available in prep. Don't let a chaotic one become the basis for show-wide color decisions.

Common ways camera test packages go wrong

Most bad packages fail for ordinary reasons. The usual problems are easy to recognize:

The chart is under mixed or uneven light.
The camera is focused behind the chart.
One camera used a different shutter, frame rate, or white balance.
A monitoring LUT was mistaken for a recorded look, or the reverse.
The final notes say “Camera B is greener” without saying under which light or transform.

The fix is stricter repeatability and better notes. If the test conditions are clear, post can interpret imperfect footage. If the test conditions are unknown, even beautiful chart frames become guesswork.

Make the package small enough to finish

There's a temptation to test everything: every ISO, every lens, every LUT, every codec, every lighting condition. That creates a giant pile of footage nobody has time to analyze. A useful camera test package is scoped around decisions. For a typical cross-brand production, the core package can be compact:

Controlled daylight chart pass for each camera
Controlled tungsten chart pass for each camera
Exposure brackets for hero and secondary cameras
Skin tone reference under key lighting conditions
Real-world mixed-light scene
Show LUT or color pipeline validation
Written recommendations for exposure, matching, dailies, and editorial labeling

For VFX productions, add gray ball, chrome ball, and color chart, plus HDRI or lighting reference as the VFX supervisor requires. For heavy HDR finishing, add highlight torture tests and display-referred review. For productions that rely on phones, drones, or action cams, add tests for internal processing and stabilization, and for sharpening and compression artifacts. The package is done when it answers the production question and gives post enough reference to rebuild the answer later.

The handoff that actually helps post

When the package moves from camera prep to post, send context with the media. The assistant editor should know which clips are technical references and which are creative tests. The colorist should know which chart frames are valid for analysis and which were casual on-set references. The post supervisor should know what decisions came out of the test. A strong handoff includes:

Original test media, plus proxies if editorial needs them
Camera reports and workflow notes
LUTs, CDLs, and transform assumptions
Stills and scope grabs
A short written recommendation tied to camera IDs and lighting conditions

The best result is unremarkable in the right way. Editorial gets consistent labels, dailies get the intended color path, and the colorist gets trustworthy references. Production gets clear exposure guidance. When pickups or season two arrive, the team can open the library and understand exactly how the original cameras were tested. That's the real value of exposure and color chart packages: shared technical memory for the whole production. Build every one of them for the assistant editor who opens the folder two seasons from now.

FAQ

A practical camera test package includes an 18 percent gray card, a color rendition chart such as an X-Rite ColorChecker, and a DSC Labs chart for scope-based matching. Add a grayscale or step wedge chart for tonal response, plus a focus or resolution chart if sharpness or lens behavior is part of the test. VFX-heavy productions may also need gray balls, chrome balls, color charts, and HDRI or lighting reference.

Shoot a normal exposure first, then capture controlled underexposed and overexposed versions, commonly at one-stop and two-stop intervals. If clipping behavior is important, add half-stop or third-stop increments near the limits. Change only one exposure variable at a time, and document whether the bracket was made with aperture, light level, ISO or EI, ND, or another method.

A chart frame can look very different depending on the transform, LUT, color management system, or display path. Testing in the intended pipeline shows whether middle gray, neutrals, skin tone, saturation, clipping, and camera matching behave as expected in the same environment that dailies, editorial references, and finishing will use.

Record camera make, model, firmware, sensor mode, resolution, codec, bit depth, log or gamma curve, color gamut, ISO or EI, shutter, frame rate, white balance, lens, filtration, internal processing settings, monitoring LUT, show LUT, CDL, and timecode mode when relevant. Without that context, chart footage is difficult or impossible to interpret later.

Store original camera media, proxies, reference stills, workflow notes, camera reports, LUTs, CDLs, transform assumptions, scope exports, colorist notes, editorial notes, and a clear readme in one structured package. The readme should describe the shoot date, cameras, charts, lighting setup, pipeline assumptions, conclusions, and known limitations so future teams can understand and reuse the test.

Treat camera ID, chart type, lighting condition, exposure offset, transform, and decision notes as searchable metadata instead of burying them in filenames. Aspect lets teams create project-specific fields so those attributes can be tracked, filtered, and sorted as custom metadata.