ORF to SVG Converter

ORF to SVG: What Works, and What Doesn't

The honest headline first: a trace is only ever as good as the raster it is given, and an Olympus .orf is not a raster. It is undeveloped Bayer sensor data — one filtered brightness value per photosite — that has to be demosaiced, white-balanced and tone-curved into RGB pixels before there are any colour boundaries for a tracer to follow. Something has to make those development decisions, and if you do not make them, defaults make them for you. The route worth taking is two steps — develop the raw into a PNG you have looked at, then trace that PNG — and both steps are one click each. This page walks through that route, explains the one setting that matters, and tells you when a photographic raw has no business becoming a vector file at all.

How to Convert ORF to SVG

1. Develop the ORF to PNG First: Run your raw through ORF to PNG. PNG is lossless and keeps full colour, so nothing the tracer could have used is thrown away — and having the render in front of you is your one chance to catch a bad exposure before it becomes vector paths. Download the PNG when it finishes.
2. Upload the PNG to the Tracer: Open PNG to SVG and drag the PNG in, or click "+ Add Files" to browse. Several images can be queued and traced with the same settings.
3. Set Number Precision: Under Advanced Options, the "Number precision" slider runs 1-10 and opens at 6. It controls how much numeric detail the trace keeps; 4-6 is the range the on-page note recommends, and there is a real reason not to push it to the top (see below).
4. Convert and Download: Click Convert and save the .svg. Files are uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours. No sign-up, no watermark.

Why the Intermediate PNG Improves the Trace

Raster-to-vector tracing is a different pipeline from raster-to-raster conversion. A converter like ORF to JPG hands the file to a raw developer that knows Olympus's sensor layout and demosaics it into RGB pixels, applying a white balance and a tone curve as it goes. The tracer does none of that thinking — it takes RGB pixels, clusters neighbouring ones whose colours are close enough, and fits curves around each cluster. It has no opinion on exposure, no way to recover a blown highlight, and no idea whether a dark region is shadow detail or noise.

That is exactly why the render step is worth doing on purpose rather than leaving to a default profile. Looking at the PNG before you trace lets you catch an exposure that would otherwise crush three separate shadow tones into one shapeless black region, denoise a high-ISO frame so the tracer follows the subject instead of the grain, and downscale a 20-megapixel capture to a size where the clusters mean something. None of that is available to you once the file is already a stack of paths. Renaming achieves nothing in either direction — an extension is a label, and the bytes inside an ORF stay a sensor mosaic whatever you call the file.

What Makes a Good Tracer Input

What "Number precision" Actually Controls

The slider feeds a single value into two places at once: the colour precision used while clustering pixels into regions, and the number of decimal places written into each path coordinate. That coupling has one practical consequence worth knowing.

• Small file, simple shapes (icons, flat logos): drop to 3-4. Coordinates get shorter and colour clustering gets coarser, so the XML shrinks noticeably.
• Clean edges on a logo, chart, or scanned line art: leave it at 6. This is the range the on-page note points at and the best all-round setting.
• Positions 9 and 10 are not usable: the underlying tracer caps colour precision at 8 bits per channel and rejects anything higher, so a run at 9 or 10 aborts instead of producing a finer trace. Stay at 8 or below.

Precision is a size-versus-detail dial, not a rescue for the wrong source image. A continuous-tone photo traces into flat, posterised colour blocks at every setting, because vectorising means replacing smooth gradients with a finite set of filled shapes.

ORF and SVG at a Glance

When Tracing Is the Wrong Tool Entirely

Camera raws exist to hold photographic detail — texture, noise, tonal gradation — and SVG has no efficient way to describe any of it. Trace a portrait or a landscape and you get a stylised, blocky approximation stored in tens of thousands of paths, often larger than the JPEG of the same photo and slow to open in a design app. Vectorising an ORF only makes sense when the frame happens to contain graphic content: a photographed logo, a whiteboard diagram, a sign, a chart, a scan of line art — anything with hard edges and a small palette. For ordinary photography, stop at the raster step: ORF to JPG for sharing, ORF to PNG for a lossless working copy, or ORF to TIFF for print and archival.

Frequently Asked Questions

What does "No image file found at specified input path" mean?

That message comes from the tracer's image loader, not from a missing or corrupt upload — it means the loader was handed something it could not open as an image at all. By far the most common cause is a file that was renamed rather than converted, so the extension promises one thing and the bytes are another. Run a genuine render with ORF to PNG and trace the result.

Can I just rename my .orf file to .png and trace it?

No. Renaming changes only the label; the bytes inside are still an Olympus raw container, and a PNG decoder handed raw sensor data finds no PNG signature to work with. A genuine decode is required, which is exactly what the ORF-to-PNG conversion performs — and the render it produces is something you can actually look at and correct before tracing.

Should I go through PNG or JPG on the way to SVG?

PNG. It is lossless, so no JPEG blocking artifacts get baked into the image before the tracer looks at it — and tracers are unusually sensitive to compression noise, because each speckle can become its own path. JPG works if that is what you already have (JPG to SVG accepts it), but a JPEG-sourced trace tends to carry more stray shapes.

Why can't I set Number precision to 9 or 10 if the slider goes that high?

The slider's range is wider than the tracer's accepted range. One slider value drives both the coordinate precision and the colour precision, and colour precision is hard-capped at 8 bits per channel — a request for 9 or 10 is rejected outright rather than clamped. Keep the slider at 8 or lower; 4-6 gives the best size-to-detail balance in practice.

Will the SVG be a real, editable vector file?

Yes. The output is standard SVG that opens in Illustrator, Inkscape, Affinity Designer, Figma, and any modern browser, and every shape is an editable path. What scalability cannot do is restore detail the trace never captured: if the source was a photograph, you get crisp edges around posterised colour blocks, not a photograph that magically became resolution-independent.

Why is my traced SVG bigger than the original photo?

Because each distinct colour region becomes its own path, and a photograph has an enormous number of them. Ten of thousands of <path> elements, each carrying a long list of coordinates, adds up fast — a detailed photo can easily out-weigh the JPEG it came from. Crop tightly to the graphic element you actually want, reduce the source resolution first, or lower Number precision to shorten every coordinate.

Does the SVG keep my EXIF data, white balance, or Olympus Picture Mode?

No. SVG describes shapes and fills; it has no container for EXIF, camera maker notes, white-balance settings, or an Art Filter/Picture Mode instruction. Those live in the ORF, and they are already resolved into fixed pixels the moment the raw is developed to PNG. Keep the .orf if you need that information later.

What happens to my files after the conversion finishes?

They are uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours — never shared, never made public. There is no sign-up and no watermark. Because Olympus raws routinely run tens of megabytes each, the practical limit on a big batch is upload size and connection speed rather than anything in the conversion itself.