What happens to the layers you don't export?

They stay in your KRA or ORA project. Exporting gives you a separate picture or set of images—and an OpenRaster export can include a note hidden from the finished picture.

FluffyBench · 6 min read · Reviewed October 15, 2026

What is inside a KRA or ORA project?

Think of layers as clear sheets stacked on a desk: you can move a drawing on one sheet without repainting the others. A KRA or ORA project keeps those pieces separate, along with a saved picture of the whole stack. That finished picture is called the merged image.

A finished-image export uses the saved picture, so FluffyBench doesn't need to rebuild the scene from its layers.

Project parts and a finished-image export

The export path uses the merged picture; the separate layer data stays inside the project. Sources and method

KRA is Krita's project format; ORA is OpenRaster, a format for exchanging layered images. Both pack the project's parts into one file.

What do KRA and ORA exports include?

Ordinary KRA and ORA conversion returns the saved merged picture as a PNG. For ORA, FluffyBench's Image extractor also gives you a choice: One image per file returns that picture; Everything inside returns it plus every stored PNG layer.

Here's a small OpenRaster project with two visible layers and a hidden note, alongside the two sets of images you can extract.

Top: the OpenRaster project's visible Background wash and Purple disc layers, plus Hidden note. Middle: One image per file returns the merged picture without the note. Bottom: Everything inside returns the merged picture and all three PNG layers, including Hidden note. — The Hidden note is absent from the finished picture and included as its own PNG with Everything inside. Each layer is copied as stored, including its transparency; it isn't repainted into a new scene.

Which layered-image output should you choose?

Choose by what you'll do next: carry on editing, share the finished picture, or work with separate OpenRaster images.

Three uses, three file choices

A PNG gives you a picture; the KRA or ORA keeps the editable layer structure.

An export checks the data it needs. Everything inside unpacks the PNG layers and checks their headers; it doesn't fully decode every layer's pixels as a project-health check.

The merged picture is copied out. A layer PNG has its header highlighted: extraction checks that header while unpacking the file, without fully decoding all its pixels. — A merged-picture request leaves the other layer image data unopened.

Doing it in FluffyBench: export OpenRaster images

Use FluffyBench's Image extractor when you need images from an ORA project. Start with Everything inside to get the picture and its PNG layers.

Step 1. Choose your ORA project from your device.
1. Choose files opens the file picker.
Step 2. Choose Everything inside for the merged picture and PNG layers.
1. Select Everything inside.
Step 3. Press Extract.
1. Extract creates the requested PNG files.
Step 4. The Hidden note has its own PNG. Check the preview and dimensions; Download saves this image.
1. Check the extracted layer picture.
2. Check the pixel size and hidden label.
3. Download saves this layer PNG.
Step 5. Use Download all (ZIP) for all the extracted images together.
1. Download all (ZIP) bundles every result.

If you need the finished picture by itself, the same ORA goes through the shorter One image per file path.

Step 1. For a finished picture, choose One image per file after adding your ORA.
1. Select One image per file.
Step 2. Press Extract with that choice selected.
1. Extract returns the saved merged picture.
Step 3. You get the saved picture, with no separate layer images. Save it using the same Download link shown above.
1. Check the finished picture.
2. Check its pixel dimensions.

FluffyBench's Image extractor saves the merged picture or all PNG layers from your ORA project.

Image extractor

How we reviewed layered-image exports

A historical FluffyBench reader update preserved the exported files byte for byte while opening fewer files inside KRA projects. These counts refer to files packed inside each project.

Setting	Earlier reader	Updated reader	What it measures
2017-10-11_run.kra — archive files opened	88 members	3 members	The large Krita project.
E40P05.kra — archive files opened	25 members	3 members	A smaller Krita project.
2014-07-01_concept-art_Pepper.kra — archive files opened	15 members	3 members	A second smaller project.
2017-10-11_run.kra — declared unpacked size	207.8 MiB	14 MiB	Declared uncompressed size of the files read.
2017-10-11_run.kra — minimum conversion time	2,211 ms	271 ms	Shortest of five historical runs.

Historical merged-picture exports from three real Krita projects. Run provenance and timing conditions are in the method note below.

The comparison covered the KRA merged PNG, ORA merged picture, PNG layers and layer count. Returned image bytes matched across the reader change. Repeating ORA extraction after Clear and KRA conversion after Reset also produced matching output hashes. Each worker setting passed 40 checks, split evenly between KRA and ORA.

In the large KRA, peak Node array-buffer memory growth changed from 402.2 MiB to 196 MiB. The historical test-only KRA-to-PNG page changed from 5,802 ms to 2,025 ms in Chromium, and from 7,539 ms to 2,592 ms in Firefox.

How we reviewed

Reviewed October 15, 2026

The real-document reads, browser comparisons, selected-output byte comparison, repeat checks, and damaged-file review come from FluffyBench selective-read measurement records for the KRA and ORA reader changes. The layered figure comes from the measurement record. Current ORA layer-selection behavior and the KRA merged-image path were checked against the source code.

The first-party layered document was written and opened locally with the extractor on a production build, in both output modes. The timing and memory rows are historical records from the selective-read changes, not a new run on this machine; they describe the implementations those changes landed on, not current-build timing. The timings on this page do not describe ordinary ORA conversion.

The comparison pictures come from the measurement record: one first-party OpenRaster document (fluffybench-layers.ora) opened with the extractor on October 15, 2026. The walkthrough archive is reconstructed from those exact PNG payloads for illustration, with the hidden note first in stack order; it is not a fresh measurement of the original archive.

Current extraction unpacks the selected PNGs and checks their headers, not a full pixel decode. Unselected ORA layers still receive path, presence, position and opacity checks. Ordinary ORA conversion reads the merged picture and stack dimensions without validating the individual layers.

Historical damaged-file checks rejected a broken later layer with all-layers extraction. The earlier first-layer mode succeeded because it did not unpack that later image; first-layer selection is not a public Take option.

Archive-file counts refer to ZIP files that were unpacked. The declared unpacked-size values are declared uncompressed totals for the files read, not exact file lengths.

The displayed conversion time is the minimum of five runs for the merged-image task.

The memory figure is peak growth in Node's arrayBuffers memory, measured in a fresh Node process per version, file, and mode. It includes the compressed source file held in memory and is not whole-browser memory.

The test-only KRA-to-PNG and Any Image scenarios are not public conversion pages, and the runs shared the machine with other work, so they are not a controlled quiet-machine benchmark. The repeat checks are pass counts on fixed inputs, not throughput benchmarks.

The real-document runs used local copies of David Revoy's Pepper&Carrot artwork under CC BY 4.0; the runs did not use a separate raster-photo corpus.