--- title: "Dual-Version Camera" date: "2026-07-29" canonical: "https://raytally.com/en/ideas/2026-07-29-idea-aa023632/" generator: "RayTally · dev-prompt-v4" signal: query: "What pisses me off is when I take a photo on my iPhone 15 and I can SEE the processing dull the colors in a split second… and I can’t undo it! Awful! Suzy Exposito (@HexPositive) July 28, 2026" observed_at: "2026-07-29T00:34:03.936Z" sources: - url: "https://x.com/HexPositive/status/2081892687305994682" boundary: "Published at 2026-07-28T00:01:11.000Z. Observed at 2026-07-29T00:34:03.936Z." - url: "https://developer.apple.com/documentation/avfoundation/capturing-photos-in-raw-and-apple-proraw-formats" boundary: "No publication timestamp is present in the source record." - url: "https://developer.apple.com/documentation/coreimage/cirawfilter" boundary: "No publication timestamp is present in the source record." - url: "https://www.lux.camera/process-zero-manual/" boundary: "Published at 2024-08-14T00:00:00.000Z." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-07-29-idea-aa023632/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Dual-Version Camera After every shot, compare the sensor original with the system-rendered photo, then keep or remove HDR, noise reduction, and color processing one setting at a time. ## Product concept After taking a portrait or night photo on a phone, people may look back and find that the system has rendered skin tones, the sky, or saturation unlike the scene. Each time the user presses the shutter, the app saves the sensor original and the system-processed image as two versions of the same photo, ready for side-by-side comparison immediately after capture. The comparison screen offers more than a choice of which version to keep. Users can retain the system’s HDR to control highlights, turn off excessive sharpening, or roll back only the color styling and skin-tone adjustments; every processing option has a toggle and before-and-after preview. The selected combination becomes a preference for the next shot without overwriting the original file. In the photo library, both versions live under one item, with the thumbnail showing the version the user ultimately chose. On export, users can select the sensor original, the full system-rendered image, or their own mixed version. The edit record stays with the photo, so users can revisit the trade-offs later without recovering an old backup. The first release supports common portrait, daytime, and night-scene processing, without claiming to replace a professional RAW workflow. Its purpose is to make every step of phone computational photography visible and reversible, rather than letting automatic beautification become an irreversible result. ## Why now (backed by facts) On July 28, an iPhone 15 user posted that the system makes colors more muted immediately after the shutter is pressed, with no way to undo it. As of July 29, the post had accumulated 661 likes, 4 reposts, and 16,068 views, making the problem of noticing a changed image immediately after capture more visible. ## Direction (model inference, not independently verified) Target user: iPhone users who care about skin tones, sky detail, and the atmosphere of the original scene. They are usually not professional photo editors, but immediately notice when a review image looks grayer, oversharpened, or has reshaped highlights. While the scene is still in front of them, they are best able to judge which version feels more faithful. By the time they edit at home, their memory has faded and an adjustable original may not have been kept. Minimal entry point: Use AVFoundation’s AVCapturePhotoOutput to make a RAW-plus-processed-photo request and obtain two outputs from the same capture on supported devices. An in-app library uses a local database to link the DNG, processed image, preview, and edit recipe. Rebuild the RAW version with Core Image’s CIRAWFilter, exposing controls for highlight recovery, local tone, noise reduction, sharpening, and white balance. The interface can still present HDR, sharpening, and color toggles, while the underlying RAW pipeline reconstructs approximate effects. Keep the system-rendered image intact as a reference, without claiming to extract every intermediate step of Apple’s processing. Prioritize daytime scenes and static portraits in the first release; enable night scenes only where device and format support permits. The strongest case against: Saving both a RAW file and a processed image with every shutter press quickly increases storage, write, and backup demands. Continuous shooting also brings processing delays, heat, and dropped frames, with a higher cost for night scenes. More importantly, public APIs do not expose Apple’s HDR, sharpening, and skin-tone processing as separate intermediate outputs. The app can only preserve the complete system version and reconstruct a controllable version from RAW. If that approximation is described as undoing a specific Apple processing step, users will quickly lose trust in the comparison. Different devices and lenses also require separate color calibration; otherwise, preferences will not transfer reliably. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) The most persuasive asset is a swipe comparison from the same shutter press. Create short videos around grayed-out skin tones, abrupt sky changes, and oversharpened night scenes, with original files available for photography users to inspect. Recruit early testers from iPhone photography communities, Halide user groups, and comments on posts discussing computational photography. Shared photo pages can retain a summary of the device and processing toggles, so posting a photo naturally surfaces the product entry point. ## Competitors & gaps (model inference) - Halide Process Zero: Halide has already made resistance to overprocessing into a mature camera experience. Process Zero creates a lightly processed image from sensor RAW and saves the RAW alongside a JPG or HEIC. Image Lab can also reprocess RAW, leaving room to adjust exposure again. It lets users switch between Apple processing and Halide’s processing, already covering the demand for more natural-looking images. Its primary choice, however, is between processing modes. Image Lab is closer to a streamlined RAW development tool than an explanation of each computational step applied to a given shot. The opening for Dual-Version Camera is to put the system version and a lightly processed version from the same shutter press into one comparison workflow. Users can also retain processing combinations by subject, without first needing to understand a RAW workflow. The real challenge is making that separation credible: its own reconstructed result cannot be presented as an intermediate layer of Apple’s pipeline. - Apple ProRAW and Photos editing: Apple ProRAW already combines RAW information with iPhone image processing in one file, preserving more room to adjust exposure, color, and white balance. AVFoundation also supports returning RAW or ProRAW and its corresponding processed image in a single request. That provides a system-level foundation for dual-version capture. But ProRAW still requires users to enter an editing interface and understand a set of conventional parameters. It does not turn the scene seen before capture, the system-rendered result, and a lightly processed version into an immediate swipe comparison. Public APIs also do not expose separate outputs for Apple’s HDR, sharpening, or skin-tone processing. Dual-Version Camera can place the professional format behind a more intuitive choice flow. Its distinction is not having RAW, but showing ordinary users what the system changed and carrying their preferences into the next shot. ## How it makes money (model inference) Use a one-time purchase model. The free version supports dual-version capture and basic comparison; the paid version unlocks the full set of processing controls, batch export, preference presets, and a persistent edit history. ## Source context Theme: iPhone photo presets and uncontrollable post-processing Trigger Web Trend observation: X @HexPositive — What pisses me off is when I take a photo on my iPhone 15 and I can SEE the processing dull the colors in a split second… and I can’t undo it! Awful! Suzy Exposito (@HexPositive) July 28, 2026 Source metric: 点赞 661 / 转发 4 / 浏览 16068 (发布后累计) This is one observation bounded by its publication and capture times. It is not evidence of market size or a broad trend and only explains “why now.” ## Sources - iPhone 15 photo processing dulls colors and cannot be undone (https://x.com/HexPositive/status/2081892687305994682) - Capturing photos in RAW and Apple ProRAW formats (https://developer.apple.com/documentation/avfoundation/capturing-photos-in-raw-and-apple-proraw-formats) - CIRAWFilter (https://developer.apple.com/documentation/coreimage/cirawfilter) - The Process Zero Manual (https://www.lux.camera/process-zero-manual/) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.