# MarsCam Modern - Software Product Design and Release Plan > By Ethan J. Hulbert - https://www.ethanjhulbert.org - ethanjhulbert@gmail.com > https://www.ethanjhulbert.org/photo/marscam-modern-driver-downloader/ **Scope:** user experience, portable Windows packaging, GUI behavior, file/folder naming, output choices, diagnostics, compatibility controls, safety boundaries, and future portability. **Technical dependency:** the extraction/translation engine is documented separately in `Mars-MR97310-Still-Image-Extraction-and-Translation-Reference-2026-10-23-Published.md`. **Current published release:** `0.7.4` (Windows x64; October 23, 2026) **Document date:** 2026-10-23 This document records **the implemented Windows GUI and the decisions behind the published initial release**, while retaining earlier design rationale and open ideas for future versions. The companion technical reference records the verified camera protocol, decoder, experiments, and engineering evidence. ## Product goal MarsCam Modern is intended to be a small, preservation-oriented desktop utility for recovering still photographs from MR97310-family cameras on current Windows systems. The normal path should be simple enough for a person who has an old camera and does not care about USB archaeology. The same application should also expose enough read-only diagnostics and compatibility controls to be useful with poorly documented rebadges and hardware revisions. The application should remain deliberately non-destructive. Its purpose is recovery, preservation, translation, and diagnosis — not camera memory management. ## Distribution model — published 0.7.4 **Release status (owner-reported): publicly downloadable as of October 23, 2026.** Initially the owner has published a small landing/download page; a larger planned "Everything About MarsCam" reference site is **not yet finished**. No installer is required for the first portable release. Public-facing download contents: ```text MarsCam-Modern-0.7.4-Windows-x64.zip MarsCam.exe README.html LICENSE.txt THIRD_PARTY.txt ``` This is deliberately **not** the developer/source ZIP. The owner compiles the `MarsCam.exe` on Windows with Visual Studio/CMake; public users unzip the four files and double-click it. A CMake option requests static MSVC runtime linkage so a separate Visual C++ Redistributable should ordinarily not be necessary. Windows itself and its standard USB/device APIs are still required. `README.html` is a styled, offline, nontechnical guide with embedded icon artwork and instructions for **Windows 10 or Windows 11**. It explains the rare 4-pin Mini-USB-B-style camera connection, power/memory risk, WinUSB driver setup through Device Manager, Hardware ID verification, safe download workflow, preview, rendering modes, collision-safe files, and troubleshooting. Device Manager instructions require matching `USB\VID_093A&PID_010E` before any driver rebind, and explicitly warn users not to install a random driver or the antique proprietary Mars driver. The present UI and README do **not** automatically change driver bindings. If WinUSB cannot be selected using the documented route, users should stop and seek guidance rather than improvising. The Help / Info panel points to `https://www.ethanjhulbert.org/photo/marscam-modern-driver-downloader/?r=mars` as the program page and links the author through `https://www.ethanjhulbert.org/?r=mars`; support email is displayed as text and the optional support link points to `https://www.ethanjhulbert.org/bmac`. These URLs are program metadata, not network dependencies of the executable. The program is independently distributed and not established here as commercially code-signed; Windows SmartScreen/unknown-publisher warnings may occur. A second-computer/Windows 11 hardware test remains worthwhile but **was not a release blocker**. The known physical device was tested under Windows 10 x64. A separate full-source package remains available for developers/preservationists, with MIT original-code licensing and explicit libgphoto2 historical attribution. No proprietary drivers or private photographic samples are distributed. Usual end-user steps: ```text 1. Extract the public Windows x64 ZIP. 2. Connect the compatible camera using its correct USB data cable. 3. Configure Microsoft's WinUSB driver once if Device Manager requires it. 4. Launch MarsCam.exe (no installer). 5. Refresh Photo List, preview/check photos, choose destination/styles, download. 6. Keep the original .emarsraw files along with desired PNGs. ``` ## Window structure — implemented 0.7.4 The application uses a **native Win32** window, not a browser, Electron app, installer, or thumbnail-library manager. The main title reads `MarsCam Modern`; the Windows title bar displays `MarsCam Modern 0.7.4`. The transparent custom camera illustration is the title-bar/taskbar/Explorer icon. The implemented flow, approximately in screen order: ```text MarsCam Modern [Camera/WinUSB status and device/family summary] [Refresh Photo List] [Device Details] [Help / Info] STORED PHOTOS — check photos to download, or click Preview to see it on the right. [checkbox] # Resolution Compression Dimensions Bytes Preview › [checkbox] # Resolution Compression Dimensions Bytes Preview › [one preview canvas] [Download Selected (X)] [Download All (N)] [Select All] [Select None] Download to: [folder path] [Browse] [Open Folder] ☐ New dated folder for each download Output styles: ☑ Restrained ☑ Balanced ☑ Expressive Optional extra sets: ☐ Brighter ☐ More Color ☐ Lower Contrast ☐ Stronger Destriping [Advanced / Debug expander] ☐ More render experiments and artifacts ☐ Extreme glitch pack (5 more) Bayer override: [BGGR (Auto) ▼] [remaining harmless diagnostic settings] [read-only, auto-scrolling Activity log] ``` The ordinary workflow presents only the useful controls. Advanced settings expand below it. The window can be reduced vertically and **scrolls** to reach controls without cutting off the bottom; extra bottom breathing room is intentional. Gray page background is moderately darkened relative to the 0.7.0 prototype, while input surfaces are clearer. Download buttons use restrained color; Select All/None have separate outlined, rounded, antialiased pill surfaces. The Activity area requires no separate decorative heading. The preview has its own clipped child window so prior/oversized images cannot leak outside it on resize. A dedicated Preview label above the pane was removed. `Refresh Photo List` clears the preview and restores the idle instruction; it never leaves a stale `Loading preview...` message unless an actual preview is in progress. ## Connection and status behavior Windows can detect device arrival/removal independently of Mars protocol traffic. The application should use that mechanism for live connection status rather than repeatedly pinging the camera. Suggested states: ```text Disconnected Camera detected — WinUSB not configured Connected Reading photo list… Ready Previewing… Downloading… Communication failed — Retry / Reconnect ``` Three concepts should remain distinct: - **hardware present:** Windows enumerates the VID/PID at all; - **WinUSB ready:** the device is bound to the expected `WINUSB` service/interface; - **camera responsive:** a Mars operation has recently succeeded. This distinction was confirmed in October 2026. The test camera was physically connected, made the normal Windows USB sound, displayed `PC`, and enumerated as `USB\VID_093A&PID_010E`, but MarsCam could not see a usable interface because the device service was empty. Device Manager showed **Dual-Mode Digital Camera** under **Other devices** with an error state. Rebinding **WinUsb Device** restored operation. The implemented GUI attempts to recognize the exact supported physical VID/PID even when the WinUSB interface is unavailable and gives actionable setup/repair guidance such as: ```text Camera detected, but WinUSB is not configured. [ Show Setup / Repair Instructions ] ``` Automating the binding can remain a later task if doing so safely requires more work. The camera can remain physically/USB-connected while internally behaving as though it has powered down or reset after being in PC mode for several minutes. No background heartbeat should be added unless testing demonstrates a real benefit. Unnecessary USB traffic is undesirable on this hardware. `Refresh Photo List` performs a new bounded PAT/config scan **only on explicit request**, clears the current preview, and resets the idle placeholder. There is no automatic/background directory polling. This is particularly important after the newly observed incident in which *one refresh showed old downloadable photos and a second showed only a new photo*; the program should not silently refresh away a potentially recoverable view. If old photos unexpectedly appear, the recommended action is to download them immediately rather than refresh again. ## Camera and device details The main status area automatically displays the camera/family and key USB status; a separate **Device Details** popup exposes additional harmless descriptor and Windows PnP information. The popup is deliberately silent, has **Copy** and **OK** actions, and does not itself send USB camera commands. Fields that require a successful scan may appear only after one. Examples: ```text Friendly device name USB VID:PID Driver/service Interface number USB BCD version Device BCD/revision Device descriptor strings Known product/family label Endpoint list and endpoint types Windows instance/device path where appropriate ``` For the verified test unit this includes data such as: ```text VID:PID 093A:010E Driver WinUSB Interface 0 USB version 1.10 Device BCD 1.00 ``` This information is useful for preservation, troubleshooting, and discovering differences between rebadges. ## Photo table and persistent selection Implemented columns: | Check | # | Resolution | Compression | Dimensions | Bytes | Preview | |---|---:|---|---|---:|---:|---| | ☐ | 1 | High (HR) | No (nP) | 352 × 288 | 101,388 | Preview › | | ☐ | 2 | High (HR) | Yes (CP) | 352 × 288 | 21,285 | Preview › | | ☐ | 3 | Low (LR) | Yes (CP) | 176 × 144 | 5,965 | Preview › | Use lowercase `n` in **nP** to remain consistent with the camera's notation and saved filenames. The **selection is the checkbox state**, not the currently highlighted row. The ~20px checkbox glyph has an independent hit area. Clicking the checkbox toggles membership in the download set **without** previewing; clicking anywhere else on the row—including its retained Preview column—loads that image into the shared preview pane **without** disturbing existing checkboxes. Checked row text becomes bold, while unchecked text returns to ordinary weight. Thus selections remain understandable even when focus changes to another control. Primary actions are `Download Selected (X)` with the current checked count and `Download All (N)` with the total photos currently listed; both have sufficient width for three-digit counts. Same-height `Select All` and `Select None` pill buttons sit immediately beside them and modify checkboxes only. A single set of rendering/output options applies to all photos in a given batch. Download All intentionally ignores the selection subset; neither action erases pictures on the camera. ## Preview — bounded, shared, explicit The camera's directory does **not** supply precomputed thumbnails. Preview therefore downloads the chosen still into memory and decodes it with the correct-path renderer. This is a **real camera read**, not a metadata-only action. - The main window has exactly one shared preview pane, with a clipped child control for correct rendering while the window resizes or a different photo is selected. - One preview transfer at a time; no automatic thumbnail grid or background prefetch of an entire camera. - Clicking a photo row outside the checkbox initiates preview. While the request is active, the pane displays the loading state. A different completed photo replaces the last one. - A completed preview is memory-only and creates no permanent `.emarsraw` or PNG files. A separate Download action is required to save it. - Clicking Refresh Photo List clears the pixels and displays the ordinary no-image guidance, not `Loading preview...`. - Preview does not alter download checkbox state. Avoid unnecessary repeated reads on hardware whose state may be unstable after lengthy USB sessions. ## Output presets The October 2026 real-world test campaign is sufficient to settle the first product-level output philosophy. The application should default to **three sane photographic interpretations per downloaded image**: ```text ☑ Restrained ☑ Balanced ☑ Expressive ``` All three are selected by default. The names describe intent, not separate decode algorithms. ### Restrained - safest / gentlest interpretation; - lower contrast and less aggressive tone/color; - intended for users who want a conservative starting point. The current `soft` recipe is the closest development equivalent. ### Balanced - recommended middle interpretation; - natural color and moderate tone lift; - intended as the general-purpose default. The current `proc21` family is the closest development equivalent. ### Expressive - brighter/punchier/more character; - more willing to lift midtones and color; - still uses the **correct** decompression and Bayer interpretation; - should not simply be an intentionally wrong Bayer/codec glitch. The current `proc20` family and some of the historically inspired Mars rendering behavior provide useful starting points, but this branch may deserve further tuning before 1.0. The current `proc23` highlight-handling recipe remains useful and should stay available under Advanced even if it is not one of the three main labels. No single current recipe won every scene. That is precisely why the normal product should deliver a small range rather than pretend there is one canonical interpretation. ### Optional additional adjustment sets Harmless global options can generate **additional copies** of every selected normal style: ```text ☐ Also create brighter versions ☐ Also create more saturated / colorful versions ☐ Also create lower-contrast versions ☐ Also create stronger-destriping versions ``` These are batch-wide settings. They apply to every selected/downloaded photo and every selected base style. For a first implementation, modifiers can each generate one additional pass per base style. Combining modifiers with one another into every possible cross-product is not required unless later testing shows that behavior is useful. Because these photographs are tiny by modern standards, producing several variants is an intentional feature rather than a storage concern. ### Fun / experimental outputs Advanced/Debug mode can generate a much larger collection, including deliberately incorrect interpretations that produce glitch art. For CP, the existing development variants have precise meanings: ```text 05-fun-rggb-proc21 correct Mars decompression deliberately wrong RGGB Bayer interpretation 06-fun-offset4-bggr-proc21 deliberately start the variable-length compressed bitstream 4 bits off 07-fun-swapsigns-bggr-baseline 08-fun-swapsigns-bggr-proc21 deliberately reverse predictive residual signs ``` These can produce rainbow gradients, false colors, checker/pixel patterns, and other spectacular distortions. They are controlled alternative interpretations, **not evidence that correct CP decoding is unstable**. Equivalent nP alternate Bayer/historical-Mars renders can also remain available. The normal interface does not force experimental files, but Advanced/Debug offers an **Experimental / glitch renders** group and a separate **Extreme glitch pack (5 more)**. The five new RGB/pixel-domain transformations — **scanline shear, channel tear, solarize/posterize, mosaic shred, digital storm** — are available to nP and CP alike. Codec misalignment and residual sign inversions apply only to CP. The sample observed after release with only `Expressive`, `Brighter`, and both experimental boxes checked produced **11 PNGs for HR+nP and 17 PNGs for HR+CP**, plus one raw per photo; the distinction is expected, not skipped downloads. Some invalid CP debug variants may safely fail and be omitted rather than padded or presented as correct decodes. These are **offline interpretations of already-read bytes**. No glitch filter invokes extra destructive camera operations. The 0.7.4 UI still provides the baseline/correct render options independently of this laboratory. ## Original/raw preservation `*.emarsraw` **is saved automatically** with every permanent photo download in the 0.7.4 GUI, whether or not a user requests any PNG presets. This is the closest available equivalent to a digital negative for the camera and costs very little storage. It should not depend on which visible PNG style boxes are selected. More technical artifacts remain optional under Advanced: ```text ☐ Save full USB transport capture ☐ Save decompressed Bayer data ☐ Save detailed USB diagnostic log ☐ Save raw PAT/header information ``` Preview is different: an explicit preview may download/decode into memory or temporary storage without permanently writing `.emarsraw` unless the user subsequently performs a download. ## Filenames The download timestamp is now **mandatory**, not optional. PAT numbers such as `001`, `002`, and `003` are only positions in the camera's current photo table and will repeat forever. Every permanent output therefore includes the host-generated **download time** at the end of the filename. Standard format: ```text YYMMDDHHMMSS ``` Examples: ```text MarsCam_001_HR-nP_restrained_261023135620.png MarsCam_001_HR-nP_balanced_261023135620.png MarsCam_001_HR-nP_expressive_261023135620.png MarsCam_002_HR-CP_balanced_261023135621.png MarsCam_001_HR-nP_261023135620.emarsraw ``` Advanced artifacts follow the same photo identity: ```text MarsCam_001_HR-nP_transfer_261023135620.bin MarsCam_001_HR-nP_bayer_261023135620.bin MarsCam_001_HR-nP_diagnostic_261023135620.json ``` The timestamp is explicitly **download/import time**, not capture time. The camera format provides no evidence of an original capture timestamp. All output variants created from one photo download should share the **same per-photo download timestamp**, even if rendering them takes several seconds. This keeps the relationship among PNG variants, `.emarsraw`, and diagnostics obvious. No custom filename editor is necessary for the first release. ## Collision-safe naming Timestamping makes collisions unlikely but does not eliminate them. The program must never silently overwrite an existing file. If an exact path already exists, append a safe suffix after the timestamp: ```text MarsCam_001_HR-nP_balanced_261023135620.png MarsCam_001_HR-nP_balanced_261023135620_02.png MarsCam_001_HR-nP_balanced_261023135620_03.png ``` The rule applies to PNGs, `.emarsraw`, transport captures, logs, sidecars, and every other permanent artifact. ## Output folders and download sessions The user chooses the destination with a standard Windows folder picker. This is implemented core behavior; **Open Folder** sits immediately beside **Browse**. Example: ```text Download to: C:\Users\...\Pictures\MarsCam [ Browse... ] ``` An optional organizational setting can still create a new dated/session folder: ```text ☐ Create a new dated/session folder for each download ``` Example (implemented from 0.7.1 onward): ```text 2026-10-23_01\ 2026-10-23_02\ 2026-10-23_03\ ``` Because filenames are already timestamped and collision-safe, session folders are for organization rather than uniqueness. If this option is disabled, files are written directly into the selected destination. ## Advanced diagnostics The ordinary user should not need to see protocol transcripts. An **Advanced** expander can expose archival, rendering, and troubleshooting options without cluttering the main workflow: ```text Additional normal recipes / explicit recipe selection Historical MARSCAM-style approximation Historical Mars/libgphoto2-style rendering Baseline/raw demosaic Generate all normal variants Generate fun / glitch variants Brighter additional sets More-color additional sets Lower-contrast additional sets Stronger-destriping additional sets Save full transport capture Save decompressed Bayer data Save detailed USB transcript Save PAT/header summary Save diagnostic metadata/sidecar ``` These options are read-only with respect to the camera. ## Debug / Compatibility mode The now-implemented **Advanced / Debug / Compatibility** area is valuable for retaining read-only decoder experimentation across rebadges and sensor/module revisions. The central reason is the Bayer discrepancy: - historical Mars/libgphoto2 behavior assumed/reported RGGB; - the verified physical `093A:010E` camera is empirically BGGR at both HR and LR, in nP and after CP decompression. It is plausible, though not proven, that other MR97310-family rebadges or hardware revisions use a different sensor orientation/layout. The implemented compatibility control allows: ```text Bayer pattern: BGGR (Auto) RGGB GRBG GBRG ``` For the verified test profile, `BGGR (Auto)` resolves to BGGR. This is a label change only; no Bayer/decode behavior was modified. Suggested explanatory text: > Most users should leave this on Automatic. Some MR97310-family cameras may use different sensor layouts. If colors appear strongly purple, green, or blue, compare the alternate Bayer patterns. A potential **future** diagnostic action, not part of the current ordinary 0.7.4 control flow: ```text [ Compare Bayer Patterns ] ``` This can decode one selected image into a temporary 2×2 comparison: ```text BGGR | RGGB GRBG | GBRG ``` No permanent files need to be written unless requested. A future button may allow: ```text [ Use this pattern for this camera ] ``` The saved local compatibility profile can be keyed conservatively by available identifiers such as: ```text VID PID device BCD/revision stable descriptor strings where present ``` This would allow the application to accumulate known-good defaults for different revisions without pretending that one specimen represents the entire family. ### Other harmless compatibility controls The deeper compatibility/debug area may eventually expose: - explicit Bayer-pattern override; - compare all Bayer phases; - baseline demosaic with no tone/color processing; - historical Mars/libgphoto2-inspired rendering; - explicit normal processing preset; - generate all known safe render variants; - compressed-decoder diagnostic output; - raw PAT display/export; - raw 12-byte image-header display/export; - decompressed Bayer export; - full USB transport export; - detailed USB transcript. These controls change only **interpretation, rendering, or saved diagnostics**. ### Controls that should not exist Debug mode must not become an arbitrary camera-command console. Do not expose: - raw vendor-command entry; - arbitrary endpoint writes; - arbitrary address bytes; - firmware/configuration writes; - delete/erase controls; - reset `19 54`; - undocumented state-mutating operations. The safety boundary remains the same at every UI depth. ## Historical MARSCAM rendering option Surviving BMPs produced by the original MARSCAM application show that the old software's rendering differs from the current modern-neutral processing: - strong warm casts can remain indoors; - row/banding artifacts are present but substantially reduced compared with current renders; - output is relatively soft; - global contrast normalization appears gentler; - extreme sensor overload such as the black-sun artifact is preserved. This suggests two conceptually different final outputs: ```text Regular / Restored ``` A modern best-looking interpretation. ```text Historical MARSCAM ``` An evidence-based approximation of the old application's appearance. The historical option should be clearly labeled as an approximation unless a matched original raw/BMP pair is eventually recovered and the old pipeline can be reconstructed more exactly. ## Diagnostic metadata/sidecars The camera does not appear to provide capture date/time EXIF-style metadata. A software-generated sidecar may still preserve everything known at import time. Possible fields: ```text camera_index downloaded_at resolution resolution_code compression stored_bytes PAT_bytes raw_header USB VID/PID device BCD selected Bayer pattern selected render preset software version ``` A sidecar format such as JSON is appropriate if added. It should not be confused with original camera metadata. ## Progress and logs The main interface displays operation progress in a read-only **RichEdit Activity log** (automatically scrolling to the newest text). Representative messages: ```text ✓ Camera initialized ✓ Photo table read ✓ 17 items found Downloading photo 3 of 17… ✓ Photo 3 decoded: Low (LR), CP ``` Detailed transfer logs stay under Advanced. Users can retain detailed logging through Advanced options, while the normal Activity log remains readable and scrollable. The Help and Device Details dialogs each have a **Copy** button to share their complete text without manually retyping diagnostics. ## Safety requirements The GUI must preserve the read-only engine philosophy: - no erase; - no delete; - no reset; - no configuration write; - no firmware write; - no generic command console; - exact-device filtering before active traffic; - bounded reads, timeouts, and loops; - raw data preserved before transformation; - no silent file overwrite. A communication error should result in a clean retry/reconnect path, not increasingly aggressive recovery commands. ## Current development outputs The **older 0.6.3 development CLI** deliberately creates more artifacts than the 0.7.4 GUI's default public three-style path. Its eight-per-photo render set is historically important but should not be mistaken for the 0.7.4 default output structure. For nP it can generate four correct-path normal comparison renders: ```text 01-normal-proc21 02-normal-proc20 03-normal-proc23 04-normal-soft ``` and four experimental/fun variants: ```text 05-fun-rggb-proc21 06-fun-bggr-mars 07-fun-rggb-baseline 08-fun-gbrg-proc21 ``` For CP it can generate: ```text 01-normal-proc21 02-normal-proc20 03-normal-proc23 04-normal-soft 05-fun-rggb-proc21 06-fun-offset4-bggr-proc21 07-fun-swapsigns-bggr-baseline 08-fun-swapsigns-bggr-proc21 ``` The October 2026 test campaign clarified an important point: the bizarre CP images in positions 05–08 are **expected**, because those variants deliberately use a wrong Bayer phase, a four-bit stream offset, or reversed predictive residual signs. They should never be treated as evidence of an intermittent failure in the correct CP decoder. The published GUI **does** map the correct-path family to `Restrained`, `Balanced`, `Expressive` and places the large experimental set under Advanced/Debug. The published GUI automatically saves `.emarsraw` and offers extra transport captures, raw PAT/header information, logs and decompressed Bayer data only when the corresponding advanced options are chosen. ## Current processing recipes The current normal recipe parameters are retained here because they define the user-facing comparison set under test: | Internal recipe | low pct | high pct | gamma | contrast | saturation | gray-world | highlight rolloff | destripe | |---|---:|---:|---:|---:|---:|---:|---:|---:| | `proc21` | .0025 | .9975 | .95 | .90 | .98 | 1.00 | .45 | .50 | | `proc20` | .0050 | .9950 | .90 | .95 | 1.00 | 1.00 | .20 | .75 | | `proc23` | .0025 | .9975 | .95 | .90 | .98 | 1.00 | .80 | .50 | | `soft` | .0010 | .9990 | 1.00 | .86 | .96 | 1.00 | .65 | .95 | These are comparison recipes, not final color science. ## Empirical validation completed before GUI release The October 2026 image-quality campaign covered bright daylight sky/clouds, buildings, foliage, severe sun/shadow contrast, dark garage/headlights, skin tone, gray concrete, and near-matched nP/CP scenes at HR/LR. Those tests justified releasing **three sensible correct-path styles** rather than claiming a single historical or mathematically canonical color rendering. Specific findings (including why psychedelic CP images were intentional alternative decodes) are documented in the technical reference. The campaign identified future color/banding tuning opportunities; it did **not** require postponing the Windows application. The user later successfully previewed and downloaded actual photographs inside the 0.7.x GUI, and reported the completed 0.7.4 build released publicly. ## Implemented Windows GUI history and release evidence ### 0.7.0 — Windows application works on real camera - First native Win32 GUI, shared decoder, live camera list and one-photo preview, bulk downloads, preserved raw and three default render intents. - Build issues encountered *before* camera access: no CMake in `PATH`, despite bundled CMake in Visual Studio; wrong forced VS2022 (`v143`) generator against the actual Visual Studio 2026 (`Visual Studio 18 2026`, `v145`); missing `` for `FOLDERID_Pictures`. All resolved in build-script/source patches. - CMake 4.3.1 bundled with Visual Studio 2026 and MSVC 19.51 compiled the core/CLI/tests before the initial GUI-only header issue was corrected. The GUI subsequently **compiled and operated successfully on the real Windows 10 camera**. - The 0.7.0 source included provenance reconstruction from available 0.6.1 camera-engine code plus the independently recovered codec and 0.6.2/0.6.3 documented rendering choices, because the exact 0.6.3 ZIP was not mounted at that construction step. This is not a claim that the proprietary historical MARSCAM source was found. ### 0.7.1 — first usability iteration - Independent photo selection checkboxes, clipping of previews to their own child surface, better contrast and muted colored Download buttons, scrolling main form and RichEdit Activity, destination controls, Help dialog. - Dated folders use `_01` even for the first batch. Added five offline extreme-glitch RGB effects for CP **and** nP. - One Windows-only GUI build fix: mixed `LONG`/`int` arguments to `std::max` (and downstream `std::clamp`) required type-safe casts. ### 0.7.2 — selection and USB details - Bigger checkboxes; checked rows are bold; clicking a row previews without changing checkbox state; dynamic `(X)` and `(N)` counts; longer Device Details output; refreshed list clears old preview. - Clarified that the observed 11 PNGs for one nP and 17 for CP in an experimental batch were expected because only CP supports bitstream-level misdecoding. ### 0.7.3 — interaction and layout polish - Increased width/padding for Download Selected/All, added outline Select All/None beside them, made Activity follow new lines, moved dated-folder setting below destination, corrected Refresh's preview placeholder. ### 0.7.4 — published version and application identity - Embedded the owner's custom **silver Vivitar camera icon** in a nine-resolution `.ico` compiled into `MarsCam.exe` using `resources/MarsCam.rc`; no runtime ICO sidecar is needed. - Help / Info and Device Details now use **silent TaskDialog** panels with Copy and OK. Help links are clickable; support email is visible plain text; copied Help text includes the actual URL destinations. Copy does not close the panel or generate USB requests. - Removed visual corner artifacts around Select All/None via owner-drawn GDI+ anti-aliased rounded border; increased vertical spacing above Bayer override. - Latest 0.7.4 source archive reports **3/3 camera-independent tests passed**. The owner confirmed a satisfactory functional application and reported it publicly published on **October 23, 2026**. Other Windows installations and Windows 11 hardware have not been independently verified in these notes. ## Publication deliverable and support material The public user-facing release is a **portable binary ZIP** containing `MarsCam.exe`, `README.html`, `LICENSE.txt`, and `THIRD_PARTY.txt`. The built EXE is **not** included in the source ZIP or README support ZIP; the owner supplies their successful Windows-compiled binary when assembling the published download. The HTML README is deliberately self-contained/offline and aimed at people unfamiliar with drivers. It includes hardware-ID verification `USB\VID_093A&PID_010E`, instructions for selecting Microsoft's **WinUsb Device** through Device Manager on Windows 10/11 where available, warnings not to use unknown drivers, battery/volatile-memory advice, a plain-language explanation of variants/`.emarsraw`, and troubleshooting. It also documents that timestamps describe **download time**, not exposure time. The companion source package and attribution notes remain separate and should be retained for long-term preservation. A more extensive "Everything About MarsCam" project page remains planned; the software itself is already publicly downloadable. A code-signing certificate, a packaged installer, Windows 11 hardware testing, and Mac/libusb port are possible future projects but **not properties of the present release**. ## Post-release camera behavior and future UI implications After leaving the physical camera connected for an extended period, the owner disconnected it and saw the LCD capacity count return to `20`. After taking one new photo and reconnecting, **one explicit Refresh Photo List displayed the older pictures (which were downloadable), excluding the newly taken photo; a second refresh displayed only the new photo**. This is a single surprising real observation; it does not establish what memory architecture caused it or show that old photos survive a complete power loss. Product lesson: keep `Refresh Photo List` **manual**, no background heartbeat/refresh, no speculative destructive recovery. If unexpectedly old entries become visible, download/preserve them immediately before the next scan. A *future* forensic snapshot feature could optionally save distinct validated PAT lists across scans for comparison, but only as read-only data and without falsely guaranteeing stale addresses remain downloadable. ## Windows-first architecture The Windows application is the priority. The code should nevertheless keep these layers distinct: ```text GUI ↓ application / camera engine ├── device model ├── photo list ├── output options ├── protocol/PAT layer ├── raw preservation ├── decompressor ├── Bayer/demosaic └── rendering/export Windows transport └── SetupAPI / WinUSB ``` This keeps a future port possible without making the Windows product unnecessarily complicated. ## macOS portability A future macOS port is plausible but not a release requirement. The portable parts are already ordinary C++ concepts: - PAT parsing; - Mars protocol state logic; - transfer sizing; - decompression; - Bayer decoding; - image processing; - output naming. The Windows-specific parts are: - device discovery; - WinUSB transport; - Windows GUI; - packaging/signing. A Mac version would replace the transport with libusb or macOS USB APIs and either reuse a cross-platform GUI layer or implement a separate native interface. Do not choose a heavyweight cross-platform framework solely for a hypothetical Mac release unless the project later has a real Mac-user need. ## Source/package checkpoint Current user-reported **published portable Windows release:** ```text MarsCam Modern 0.7.4 — released 2026-10-23 ``` Current examined developer archive: `MarsCam-0-7-4-source.zip`; SHA-256 of the particular archive used for this documentation revision: ```text dd6d4c47e1a83efd404d7c771c193fa9ce50338a93347d3f83589dafc5f51694 ``` The initial known-good CLI checkpoint remains **0.6.3**, whose earlier source archive SHA-256 was: ```text 7450bdf6ca94ffc2382761fe57c4d023472ddaffad76d0e82e94743356eed9a6 ``` The 0.7.4 source builds a native Windows GUI as `MarsCam.exe` and additionally retains diagnostic `marscam-cli.exe` and `marsrawlab.exe`. The Windows build launcher detects Visual Studio 2026 (`Visual Studio 18 2026`) or 2022 (`Visual Studio 17 2022`) and their bundled CMake; uses isolated `build-vs18-x64` or `build-vs17-x64`; runs the camera-independent CTest targets; and copies the built program to the project's top level. Source ZIPs omit `build/`, CMake caches and private example photographs. The owner later assembled a public binary ZIP and reported it posted online. The source ZIP checksum above **does not** identify or authenticate that separately assembled binary ZIP; record a public-release ZIP hash independently if future reproducibility calls for it. ## Licensing and attribution The intended project license is MIT for original MarsCam Modern code. Relevant historical/protocol behavior was researched from libgphoto2 Mars support, which is LGPL. Attribution should remain explicit for the protocol, transfer layout, PAT handling background, historical image processing, and compressed decoder behavior. Do not redistribute old proprietary Windows driver binaries as part of the modern application. Do not claim that the proprietary MARSCAM Windows application source was recovered; it was not. ## Release principle Normal mode should be simple. Advanced mode should be informative. Debug/Compatibility mode should be flexible. None of them should be destructive. The application should be opinionated where the physical evidence is strong, while always retaining a harmless override path for rebadges or revisions that behave differently. At this revision, **the first GUI has been built, used with the physical camera, iterated through 0.7.4, and published**. Future changes can be incremental quality and compatibility improvements rather than prerequisites for the original recovery goal. The published program protects original recovered data first and treats imaginative variants as optional second-order interpretation.