Auto white balance, flash on, free-aim framing: every camera default that ships in consumer apps is wrong for clinical skin photography.

The serial-comparison problem

If you are tracking a skin condition over time, the photographs are only useful to the extent that they are comparable. A photo of your face on Tuesday with daylight from the left and one on Friday with overhead fluorescent and a flash fill is not two data points on the same scale; it is two photos under different conditions, and the variation between them is dominated by the camera and lighting differences, not the disease changes.

The published clinical-photography literature has been working on this problem for at least 30 years (see the Nicholson et al. JAAD 2022 piece on practical strategies for clinical photography of dark skin, the Lakhan and Lynch BJD 2022 note on standardized clinical photography across skin tones, and the longer-running clinical-photography review literature; also the Canfield VISIA-CR documentation as the pharma-trial reference). The protocols are explicit, the bar is high, and the consumer-app category has mostly not implemented any of them.

The result is a category-wide failure to produce serial-comparable photographs. Patients are accumulating photo libraries that look, in the moment, like documentation of their disease, but that cannot be compared across visits because the conditions varied between captures. The photos exist; the comparability does not.

What the published protocol says

The standardized clinical-photography protocol for dermatology is well-documented. The Nicholson 2022 JAAD piece and the broader review literature (Cosmoderma, the Canfield white-balance primer, the Lakhan 2022 BJD note) converge on the same set of recommendations:

- Lighting. Consistent, high-quality, bright light held close to the skin at an angle that does not produce glare. LED light source is described in the literature as superior to flash for minimizing glare and producing uniform lighting. The light source should be parallel to the face at face level. - White balance. Auto white balance is explicitly discouraged for serial clinical photography. The reason is that auto-WB varies frame-to-frame with ambient color content; a photo taken at sunset is white-balanced differently than a photo taken at noon under the same camera. For serial photography, the WB is manually locked to the dominant light source (daylight around 5500K, indoor tungsten around 3200K, mixed sources matched to the dominant one). For applications where the color of the lesion is the variable being tracked (vascular conditions, pigmentary conditions, rosacea), color charts or 18 percent gray cards are recommended in the frame. - No flash. Flash creates specular hotspots that destroy erythema scoring. The literature is consistent on this: flash off, always. - Background. Even, neutral, non-reflective, monochromatic, white or mid-grey or blue. Dark blue background is specifically recommended for visualizing erythema in skin of color, because the red contrast against dark blue amplifies the visibility of redness that would otherwise be lost against a lighter background. - Distance, angle, framing. Standardized: front view plus 45 degree views plus 90 degree views (right and left), patient seated, head in the Frankfurt horizontal plane, neutral expression, hair pulled back, glasses off. Focal length is effectively 50 to 100 mm equivalent (a moderate telephoto, not a wide-angle) to avoid lens-distortion artifacts in the face. - Cross-polarized photography for vascular conditions. Two polarizers oriented perpendicularly, one on the lens and one on the light source, cancel surface reflection and surface specular highlights. The captured image emphasizes subsurface vasculature and erythema. This is what the VISIA-CR system (Canfield Scientific) does for clinical-trial-grade dermatology imaging.

None of these is exotic technology. The protocols have been documented and refined over decades. The barrier to consumer-app adoption is not technical capability; it is the design choice to inherit camera defaults rather than build a clinical-grade capture pipeline.

What the iPhone camera does by default

The iPhone Camera framework (AVFoundation), used unmodified, produces a capture that fails the clinical protocol on almost every dimension.

The default behavior:

- Auto-exposure and auto-white-balance are on by default. Every frame is balanced to the ambient color content of that specific moment. Two photos in the same lighting, taken seconds apart, can balance differently if the framing shifts slightly. Across days, the WB drift is large enough to make erythema comparison meaningless. - HDR and computational photography pipelines run by default. Apple's image-signal processor applies tone mapping, noise reduction, and exposure compensation across the frame. The mapping is opaque, varies by iOS version, and is not consistent across frames. For aesthetic photography this is helpful; for serial clinical-photography it is the wrong direction. The actual color values in the saved image reflect the processing pipeline as much as the captured scene. - Flash auto by default. When the camera judges the scene under-exposed, the flash fires. Specular hotspots appear. Erythema disappears under the wash. - No fixed-distance enforcement. The framing varies with how the user holds the phone, how far they stand from the camera or mirror, and whether they remember to match the previous capture's framing. - No fixed-angle enforcement. Same problem; the patient picks the angle freely, and the angle varies across sessions.

An app that takes a photo and saves it without overriding any of these defaults is producing a photograph that is shaped more by the iOS camera pipeline than by the disease being tracked. The shape is not random, but it is not comparable across sessions either.

What is translatable to consumer hardware

The good news is that most of the clinical-photography protocol IS translatable to an iPhone, if the app is built around the goal rather than inheriting the camera-app defaults.

What the AVCaptureDevice API supports:

- Manual WB lock. AVCaptureDevice exposes `setWhiteBalanceModeLockedWithDeviceWhiteBalanceGains:` for locking white balance to a known reference. The right pattern is to capture a reference frame at first use (under the user's typical lighting), lock the WB to that reference, and reuse the lock for subsequent captures in the same session and across sessions. - Manual exposure lock. Same API surface; AE can be locked to a known reference frame. Combined with the WB lock, this eliminates the two largest sources of frame-to-frame variation. - Flash off, always. The flash is a software-controlled element; an app can simply disable it. - Distance enforcement via Vision/ARKit face geometry. Vision and ARKit can detect the face frame and compute the face-to-camera distance in real time. The capture pipeline can require the face to fill a fixed percentage of the frame before allowing the shutter. This produces fixed-distance captures across sessions, which the manual camera app cannot. - Angle enforcement via device pose. CoreMotion gives device pitch, yaw, and roll. The capture pipeline can require the device to be near-vertical and the face to be near-frontal before allowing the shutter for the front view; similar for the 45 and 90 degree views. - Onscreen lighting prompts. The phone's own screen can be used as a diffuse front light source (the iOS Selfie Light technique). Combined with onboarding guidance to face a window with daylight from the front (not back-lighting), this approximates the published front-source recommendation. - Background guidance. A simple onboarding tip can prompt the user to capture against a solid dark blue or neutral grey wall, particularly for skin of color where the dark blue background is the literature's recommendation.

What is NOT translatable to consumer hardware without an accessory:

- True cross-polarization. Requires a hardware polarizing rig. Validated smartphone cross-polarization attachments exist (the Lakhan 2022 BJD note discusses one validated against VISIA-CR), but they require user purchase. This is a possible v2 hardware affordance, not a v1 default. - Color calibration cards in every frame. Could be a v1.5 affordance ("hold this gray card up the first time you capture"). Reasonable but cuts user adoption to do at every capture. - VISIA-grade RBX channel separation. Proprietary to Canfield. Not reproducible on consumer hardware.

The right v0 implementation is: AE and WB locked at first capture, flash always off, distance and angle enforced via Vision and CoreMotion, and onboarding tips on lighting and background. This produces a serial-comparable photograph on consumer hardware. The clinical bar for cross-polarization is not reached, but the floor under serial-comparability is.

What Skinframe ships

Skinframe's photo capture pipeline is built around the published serial-comparability bar.

First-capture flow: the patient establishes a 7-day baseline series. On the first capture, the AVCaptureDevice white balance and exposure are locked to the conditions of that capture. Vision detects the face geometry, computes the fixed distance and the frontal-pose requirement, and stores them as the patient's standard. Subsequent captures replay this standard: WB locked to the baseline reference, distance and angle enforced before the shutter fires, flash always off.

Lighting guidance is onboarding-level. The patient is prompted, on the first capture, to face a window with daylight from the front, to avoid back-lighting, and to use a neutral background. The onboarding screen surfaces the dark-blue-background recommendation for users who indicated Fitzpatrick IV through VI (the skin-tone-branched onboarding flow, see our companion piece on rosacea in skin of color).

The captured images are stored on-device in the patient's private iCloud container, never sent to a Skinframe server. The dermatologist-handoff PDF includes a representative good-day and bad-day photo from the visit window, with the timestamps; the methodology footer notes the capture protocol so a clinician scanning the PDF knows the two photos are produced under matched conditions.

The v0 does not ship cross-polarization. A v2 affordance for cross-pol hardware attachments is on the roadmap, contingent on the validated consumer attachments staying available and on enough patients wanting to use them. For most users, the WB-locked, fixed-distance, no-flash AVCaptureDevice pipeline produces the comparable serial photographs the clinical protocol asks for, on the hardware patients already own.

How to evaluate a skin tracker's photo pipeline

If you are evaluating a skin or rosacea tracker, four questions for its photo pipeline.

1. Does it lock white balance after the first capture, or does it use auto-WB? Auto-WB is the published failure mode. If the app does not document that it locks WB, you should assume it inherits the auto-WB default from the iOS camera framework, which means the photos are not serially comparable.
2. Does it disable flash? Flash creates specular hotspots that destroy erythema scoring. An app that uses the system camera in auto-flash mode is producing photos that fail clinical photography on this dimension. Skinframe disables flash always.
3. Does it enforce framing (distance and angle), or does it allow free-form selfies? Vision and ARKit make the enforcement possible. An app that does not implement it is producing photos with frame-to-frame framing drift; the disease changes get lost in the framing changes.
4. Does it surface the capture protocol on the derm-handoff? A photo's clinical value depends on a clinician being able to trust the conditions under which it was captured. A handoff that names the protocol (WB locked, no flash, distance enforced, lighting from front, neutral background) lets the dermatologist trust the comparison. A handoff that just shows the photos asks the dermatologist to take the pipeline on faith.

Most consumer skin apps fail at least three of these. The published clinical-photography protocol has been available for decades. The barrier to implementation is not technical; it is the design choice to ship a camera app rather than a clinical-photography pipeline.