Migrating: Krita (.kra)

Policy

Krita import follows the same shared policy documented in full on the OpenRaster guide: best-effort raster-safe subset, a data (not prose) fidelity report with mapped | degraded | dropped verdicts, source preservation of the original .kra as a role: "master" blob, and content-based (not filename-based) detection — a .kra file is distinguished from an .ora file by zip-member sniffing: the presence of maindoc.xml versus an ORA mimetype member, never by extension.

Scope

Per design D6, this is deliberately the most constrained of the four importers:

• Parse maindoc.xml for the layer tree.
• Where layer pixel data is available as embedded, already-rasterized content (file layers, some paint layers) — use it directly, mapped.
• Otherwise, per layer: use a derivable visible-flatten of that layer if one exists, else drop the layer with a dropped verdict naming it — never a silent omission from the resulting document.
• Krita's internal tile format is explicitly out of scope. Attempting a from-scratch Krita tile-codec implementation is, per the design's consultant consensus, the textbook edge-case tar pit this format's import policy is built to avoid — it's a "best-effort raster subset," not "full Krita fidelity."

What this means in practice

A Krita document with straightforward paint layers and groups should import cleanly (mapped). A document leaning on Krita-specific features the importer doesn't understand — vector layers backed by Krita's own vector format, filter layers, complex tile-encoded brush strokes it can't flatten — will surface those as degraded or dropped items in the pre-commit fidelity dialog, and the original file is always recoverable from the stored source blob regardless of what the import kept.

Blend-mode mapping (generated from import-krita)

Krita's compositeop vocabulary (KoCompositeOpRegistry.h) is package-local to @faceless-photolib/import-krita (mapKritaCompositeOp) — it is NOT the shared ORA/PSD table, because Krita's 100+ op registry mostly has no blend-function equivalent. Every one of the native 27 modes does have a Krita id (note the registry's own spellings: burn, dodge, luminize, diff). This table is rendered from that exact code at build time; the degraded row shows representative exotic ids — any unmapped id degrades to normal the same way, never a nearest-match guess:

Krita compositeop	Native mode	Verdict
normal	normal	mapped
dissolve	dissolve	mapped
darken	darken	mapped
multiply	multiply	mapped
burn	colorBurn	mapped
linear_burn	linearBurn	mapped
darker color	darkerColor	mapped
lighten	lighten	mapped
screen	screen	mapped
dodge	colorDodge	mapped
linear_dodge	linearDodge	mapped
lighter color	lighterColor	mapped
overlay	overlay	mapped
soft_light	softLight	mapped
hard_light	hardLight	mapped
vivid_light	vividLight	mapped
linear light	linearLight	mapped
pin_light	pinLight	mapped
hard mix	hardMix	mapped
diff	difference	mapped
exclusion	exclusion	mapped
subtract	subtract	mapped
divide	divide	mapped
hue	hue	mapped
saturation	saturation	mapped
color	color	mapped
luminize	luminosity	mapped
erase, copy, grain_merge, grain_extract, greater	normal	degraded

Corpus samples

Every Krita fixture in the sample corpus is served through the same /api/samples/<id> proxy every other demo on this site uses; no direct storage URL ever appears in this page. "Open in editor" runs the real import pipeline end to end, fidelity dialog included.

Samples — import-krita

Run checks in Test Lab

Preparing sample list…

Next

OpenRaster · Photoshop · Flat images