Frequently Asked Questions

Store the numeric slider values (contrast, brightness, shadows, highlights, grain) returned by BWConverter in your DAM or CMS. When you reopen the converter, hydrate those values before triggering the worker message—our WebAssembly pipeline is deterministic, so identical inputs produce identical results.

Yes. Bundle `/worker.js` with your front-end build, capture both the colour original and BWConverter output via `downloadCanvasImage`, and save the preset metadata alongside the assets. The integration checklist at `/image-black-and-white-converter` shows the exact pattern.

Cull and colour-correct in Lightroom or Capture One, export 16-bit TIFF or high-quality JPEG files, and then run them through BWConverter for monochrome mastering. Use the QA checklist on `/how-to-use` together with the newborn case study timeline to validate tone curves before delivering galleries.

The hosted UI caps uploads at 10 MB for performance, but the engine itself handles substantially larger files when self-hosted. For 40+ MP frames, convert to a 16-bit TIFF or JPEG before upload, or embed the worker locally without the UI limit.

No. We render to a canvas that matches the original width and height. If you need to constrain file size, pass a `maxBytes` value to `downloadCanvasImage`—this preserves resolution while adjusting compression.

Absolutely. Duplicate any object in `DEFAULT_PRESETS`, tweak the numbers, and persist it via local storage or your CMS schema. The converter automatically recognises presets that follow the same shape.

No image pixels ever leave your browser. Optional Google Analytics collects anonymous usage data (page views, load times) only—review `/privacy` for the full statement.

Share the signed Statement of Intent on `/about`, capture a network log that shows zero upload requests during conversion, and attach the QA checklist from `/how-to-use` to demonstrate your process.

Yes. Serve the app from a local server or bundle it with a Chromium kiosk/Electron shell. Workers and the WebAssembly engine have no external API dependencies.

High-resolution frames can exhaust browser memory. Downsize the file before previewing or move final exports to the `/batch-black-and-white-converter` worker, which processes one frame at a time.

Ensure every download call includes the `maxBytes` parameter and confirm the output size in your QA log. This keeps exports within print or CMS restrictions.

Download verified before/after frames from `/samples/` or inside the newborn guide. Each sample notes the preset and settings used so you can reproduce the look.

Listen to slider change events, store the values in your analytics platform, and associate them with session IDs. This helps you learn which looks your team prefers and whether additional presets are needed.

Yes. Use Node + Puppeteer to run the converter headlessly, process reference images, and compare histograms against the `/samples/` outputs during automated tests.

The `/batch-black-and-white-converter` route exposes the same worker used in the UI. You can instantiate it inside your own app, feed it a file list, and retrieve processed ImageData objects for downstream automation.