GIMP has carried an awkward format problem for most of its existence. The native save format, XCF, was designed entirely for GIMP’s internal data model and has never been readable by any other mainstream application. Photoshop’s PSD format, meanwhile, was a de facto standard for layered files across the industry — but GIMP’s PSD support was long enough plagued by gaps in layer mode translation, smart object handling, and adjustment layer fidelity that passing files between the two applications required accepting real data loss. GIMP 3.4 addresses both sides of that problem, and the changes are worth understanding in some technical depth before you rearrange your workflow around them.
The XCF Problem and What a “Project Format” Actually Means
XCF — the eXperimental Computing Facility format, named for the UC Berkeley facility where early GIMP development happened — stores everything GIMP knows about an image: layer stack, layer modes, channel data, paths, guides, parasites (GIMP’s term for arbitrary metadata attachments), and undo history in newer variants. It is genuinely comprehensive for GIMP’s own purposes. The problem is that “comprehensive for GIMP” has always meant “opaque to everything else.” Drop an XCF file into any other image application and you will either get an import error or, at best, a flattened approximation.
GIMP 3.4’s new project format — currently referred to internally as .gimpproject, though the final naming convention may still shift before wide release — takes a different architectural approach. Rather than a single monolithic binary blob, it wraps assets and layer data in a structured container, closer in spirit to how an ODP or DOCX file packages its components inside a ZIP archive. The advantage is that individual assets remain independently accessible, which matters for scripting, version control, and long-term file sustainability.
Whether this makes the format interoperable in the short term is a separate question. Native interoperability requires other applications to implement support, and that does not happen on any timeline GIMP controls. What the structural choice does accomplish immediately is making the format more auditable: you can inspect what is inside a project container without specialized tooling, which is a meaningful property for archival purposes. For a longer treatment of why format transparency matters over time, our article on file format sustainability and digital preservation covers the underlying principles.
PSD Compatibility: What Changed and Where the Gaps Were
GIMP’s PSD import and export has improved incrementally across many versions, but 3.4 represents a more systematic pass at the translation layer. The core difficulty with PSD compatibility is that the format was documented officially by Adobe only partially and informally for many years, and much of what community implementations know about it was reverse-engineered. The format also carries significant version complexity: a 2006 PSD and a 2024 PSD with smart objects, adjustment layers, and linked assets share the same file extension but are structurally quite different documents.
The changes in GIMP 3.4 target a few specific categories:
-
Layer blend mode translation. Photoshop and GIMP use different internal blend mode implementations in several cases, particularly for modes like Linear Light, Hard Mix, and Vivid Light. Prior versions of GIMP would either silently substitute a different mode or discard the mode information on import. The 3.4 work maps a larger set of modes more faithfully, though some modes remain approximations because GIMP’s compositing math differs at the implementation level.
-
16-bit and 32-bit channel depth. GIMP 2.x had a complicated relationship with high bit-depth PSD files because its internal pipeline was not consistently 16-bit throughout. GIMP 3.0 rebuilt the pipeline using GEGL (Generic Graphics Library), enabling genuine 32-bit float processing throughout the compositing stack. GIMP 3.4 builds on that to improve round-tripping of high-depth PSDs without silently quantizing channel data back to 8-bit on export.
-
Text layer handling. Text stored in a PSD is held in two forms: a rendered pixel representation and a structured text descriptor containing the original string, font reference, character style, and paragraph style. GIMP has historically discarded or poorly reproduced the structured descriptor on import, reducing text layers to rasterized content. The 3.4 improvements preserve more of the text descriptor data, though full fidelity — including complex paragraph styling — remains partially limited by differences in how Pango (GIMP’s text engine) and Photoshop’s own engine represent text metrics.
-
Adjustment layers. These are PSD-native non-destructive layers that apply tonal or color operations to layers below them. GIMP has no direct equivalent to most Photoshop adjustment layer types. The practical outcome is that adjustment layers still get flattened during import, which is a structural limitation rather than an implementation gap — GIMP simply does not have an Exposure or Hue/Saturation adjustment layer object to map them to.
For a more detailed look at what the PSD improvements mean specifically for editing workflows, the companion piece GIMP 3.4’s New PSD Support: What It Means for Your Editing Workflow goes further into the practical exchange scenarios.
What Still Gets Lost in Translation
Even with the 3.4 improvements, some categories of PSD content remain outside GIMP’s reach. Smart Objects — Photoshop’s mechanism for embedding linked or embedded source files within a PSD, preserving them as non-destructively editable references — have no equivalent in GIMP’s data model. On import, GIMP rasterizes smart object layers to their current pixel state. Any parametric or vector data they contained is gone.
Layer effects (drop shadows, stroke effects, bevel and emboss, pattern overlays applied as live layer style properties) are similarly not preserved as editable properties. GIMP imports the rendered appearance as pixel content, not the underlying effect parameters.
Channel data beyond the standard RGB and alpha — including spot color channels used in print workflows — may also be handled inconsistently. If you are using PSD as a delivery format for commercial print with spot color separation, check the specific behavior of GIMP 3.4 against your files before assuming compatibility.
None of this is a criticism particular to GIMP. Photoshop Elements loses much of the same PSD complexity, and several commercial applications that advertise PSD support make similar silently-lossy translations. The important practice is to test a representative file from your actual workflow before committing to any cross-application pipeline.
The XCF-to-Project Migration Question
Users with large archives of XCF files face a practical question: whether to migrate those files to the new project format or continue using XCF for existing projects. GIMP 3.4 continues to read and write XCF, so there is no forced migration. XCF remains more compact for single-image, layer-heavy files because it does not carry the container overhead of the project format’s structure.
The project format’s advantages show most clearly in specific scenarios: projects that reference external assets, projects where you want version control to track individual layer changes rather than treating the whole file as a binary blob, or collaborative contexts where multiple contributors might need to inspect file contents without opening GIMP itself.
For straightforward photography work — single-image retouching, compositing with a modest layer count — XCF may continue to be the more practical choice simply because it is faster to save and smaller on disk for files that do not need the project container’s features.
A Practical Approach Before Changing Anything
Given that GIMP 3.4 represents a significant internal refactor rather than just a feature addition, the sensible approach for anyone with an established workflow is to treat it as a parallel installation initially rather than an immediate replacement. Open a selection of your actual working files — PSDs from collaborators, XCFs from existing projects, high-bit-depth files if you use them — and verify that what GIMP 3.4 shows you matches your expectations before moving fully across.
Pay particular attention to any file that contains text layers you intend to re-edit, layer modes that are not straightforward multiply or screen composites, and any content that originated as a Smart Object. Export from GIMP 3.4 back to PSD, then reopen the result in Photoshop or whatever application your collaborators use, and compare the two side by side. The differences that matter to your specific use case will surface quickly, and you will have a clear picture of where the new translation holds up and where you need to maintain a different exchange strategy.