# psd_sdk: reading Photoshop PSD files from C++ without Photoshop > psd_sdk is a C++ library that parses Photoshop PSD files directly, including groups, nested layers, masks, smart objects and every compression type Photoshop uses. The visible fork adds PSB and smart object support plus loading from memory, and the build story is still Visual Studio solutions and a handful of files to port. **MolecularMatters/psd_sdk** — A C++ library that directly reads Photoshop PSD files. - Repository: https://github.com/MolecularMatters/psd_sdk - Website: https://molecular-matters.com/products_psd_sdk.html - Stars: 674 · Forks: 95 - Language: C++ - License: BSD-2-Clause - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/molecularmatters-psd-sdk ## What the library claims to read out of a PSD psd_sdk is a C++ library that directly reads Photoshop PSD files, and the README enumerates the format features it supports. Groups and nested layers are covered, as are smart objects, user and vector masks, transparency masks and additional alpha channels. Depth is handled explicitly. The library supports 8-bit, 16-bit and 32-bit data in grayscale and RGB color mode, and the README states that all compression types known to Photoshop are supported. That last item is the one that separates a real parser from a demo, because a PSD layer can store its pixels in any of several compression schemes and a reader that misses one silently produces garbage rather than failing loudly. Writing is a different story. The README says limited export functionality is also supported, and that is the phrase to hold on to. A tool that reads the full layer tree, masks and channels but can only write a limited set of things is a reader with an export side, not a round-trip document model. If your pipeline needs to modify a PSD and save it back with layers intact, the asymmetry is the fact that matters. For more background the README points to the project's own product page at molecular-matters.com. The top level of the repository is `bin/`, `build/`, `src/` and a CMakeLists.txt, so the layout is small and readable. ## The fork adds PSB, smart objects and loading from memory The README opens with a section titled THIS FORK ADD, which is the most useful thing on the page for anyone deciding whether to use this copy rather than the original. It lists three additions. PSB support means the library can read the large document format used for files too big for the standard PSD container, which matters for print and asset pipelines that produce layered files with many layers. Smart object support is the second item, and that is the feature that a lot of design-tool integrations need, since a smart object carries embedded content and a transform that the layer tree has to represent. The third addition is open from memory support, meaning the file bytes do not have to live on disk. That is the difference between a library that requires a temporary file and one that can be used inside a service that already holds the asset in a buffer, for example one behind an upload endpoint or a renderer working from a cache. The word fork in that heading matters for maintenance reasons, and the repository facts bear it out. The repository is not archived and the last push was on 2026-08-11, so the work is still happening, but there are no GitHub releases attached, which means version pinning has to be done on a commit rather than on a tag. ## Building means Visual Studio solutions, CMake or three files to port The build section is where this project shows its age and its shape at the same time. The `build/` directory contains Visual Studio projects and solutions for VS 2008, 2010, 2012, 2013, 2015, 2017 and 2019, and the `src/` directory holds the library source along with a sample application that shows how to read and write PSD files. The `bin/` directory contains a Photoshop PSD file used by that sample code. A CMakeLists.txt sits at the top level, so a CMake path exists alongside the Visual Studio solutions, though the README does not walk through it step by step. The porting section is the most useful part for a non-Windows team, and it is unusually specific. The README states that 98 percent of the code is written in a platform-independent way already, then names the three things that need porting. `PsdNativeFile.cpp` provides an implementation of the PsdFile interface and uses native Windows functions for async operations, so it is the file that ties the library to the platform. `PsdEndianConversion.inl` uses either `_byteswap_*` or `__builtin_bswap*` functions, which MSVC, Clang and GCC all provide, but the file needs porting for compilers that offer neither. `PsdCompilerMacros.h` provides an abstraction over certain compiler and preprocessor features and should already work for MSVC, Clang and GCC. So the port is three files, and the hard one is the first, because async file operations are where the platform differences actually live. ## The macOS path is a working directory trick, and the sample proves it The macOS section is short enough to be quoted in full, and it tells you something about the sample application's design. When building and debugging the PsdSamples command line utility under Xcode, you need to edit the current scheme's working directory so it can locate the supplied PSD file, and the README says to set that working directory to the `build/Xcode directory` inside wherever you checked out the psd_sdk source code. Running the binary directly from the command line is described as a little trickier: copy the binary from whatever output location it is in to `build/Xcode`, and then execute it. The reason is the sample's file path. The PSD file that the sample reads lives in `bin/`, and the sample resolves it relative to the working directory rather than relative to the executable. That is a normal choice for a sample, but it means the utility will not find its input unless you set the directory correctly, and the README is explicit that this bites people twice, once in the IDE and once on the command line. For a Linux user, the platform support statement covers the ground: the SDK compiles for Windows, MacOS and Linux. The MacOS port was kindly provided by Oluseyi Sonaiya and the Linux port was done by the user linked from the README. The porting to other platforms section is the mechanism by which a new platform gets added, and the README says the developers do not plan to support mobile platforms themselves, since they are primarily a Windows developer, while saying they would gladly accept pull requests to help out. ## First use means running the PsdSamples utility against the bundled file The repository does not document an install step, because there is nothing to install. This is a C++ library, not a package on a registry, and the way you consume it is by adding the source to your project. The upstream product page at molecular-matters.com is where the README sends you for more information. What the repository does give you is a working example, which is the fastest way to see the library do something. The `src/` directory contains the library source code along with a sample application that shows how to use the SDK in order to read and write PSD files, and the `bin/` directory contains a Photoshop PSD file used by that sample code. The sample is a command line utility named PsdSamples. The bundled file matters more than it looks. Because the sample resolves that file relative to the working directory, and because the macOS section of the README tells you to point the working directory at the build output, the sample is set up so that a correct checkout gives you a working program with no fixture of your own. A file you pass from elsewhere is where path assumptions usually surface. The other thing to know before writing code against this is that the PSD format stores layers as a tree, not a list. The library exposes groups and nested layers, so a document with an artboard inside a group inside a group is a hierarchy your code has to walk, and a flat assumption about layers will produce a partially rendered result. The sample in `src/` is the place to see how that traversal is expected to be written. ## Compared with a scripting-layer approach to the same problem The alternative for reading PSD files in an application is not another C++ parser, it is not using a C++ parser at all. A scripting-layer approach means driving Photoshop itself, through AppleScript on macOS, through a COM or scripting bridge on Windows, or through a hosted service. The difference in approach is that the scripting route reads the document through the application that owns the format, so it sees exactly what a designer sees, including anything the parser has not implemented. The cost is that Photoshop has to be installed, licensed and running, the operation is slow, and it does not work on a server or in a headless pipeline. psd_sdk inverts that. It is a direct read of the file format with no dependency on Adobe software, so it runs anywhere the C++ toolchain runs, on a render farm or a headless server, and it is fast because it is not going through an application. The price is fidelity. The library covers what the README lists, and it does not claim the complete Photoshop feature set, so a document using a feature outside that list will produce incomplete or incorrect results rather than an error. A second alternative is converting the file once, at build time, into an interchange format, and reading that at runtime. That moves the parsing cost out of the runtime path and lets you use any image library, at the cost of a conversion step, a loss of the layer tree in most interchange formats, and a pipeline where the PSD is the source of truth but the converted file is what everything else sees. The licence is BSD-2-Clause, which is permissive, with the terms in the LICENSE file at the repository root. That is a straightforward commercial position for a library you intend to link into a product, and it is not legal advice. ## Conclusion Adopt psd_sdk when your C++ application needs to open PSD files at runtime without Photoshop present, and when you need the layer tree, masks and alpha channels rather than a flattened image. Do not adopt it if you need a maintained package with regular releases, since the repository has no GitHub releases attached, or if you need to render layers to pixels, because the export support is described as limited. Verify first that the three files named for porting, PsdNativeFile.cpp, PsdEndianConversion.inl and PsdCompilerMacros.h, build cleanly on your toolchain, since the README states that 98 percent of the code is already platform independent. ## FAQ ### What file formats and features does psd_sdk support? The library reads Photoshop PSD files directly, supporting groups, nested layers, smart objects, user and vector masks, transparency masks and additional alpha channels, with 8-bit, 16-bit and 32-bit data in grayscale and RGB color mode. It also handles all compression types known to Photoshop. ### What does this fork of psd_sdk add to the original library? The README lists three additions: PSB support, smart object support, and open from memory support, which lets the library read a file that is not on disk. The repository is not archived and the last push was on 2026-08-11, but it has no GitHub releases attached. ### How do I build psd_sdk on a non-Windows platform? The SDK compiles for Windows, MacOS and Linux, and the README states that 98 percent of the code is platform independent, naming three files that need porting: PsdNativeFile.cpp for the Windows async file operations, PsdEndianConversion.inl for byte swapping, and PsdCompilerMacros.h for compiler feature macros. ### Can psd_sdk write and modify PSD files? The README says limited export functionality is supported, alongside a sample application that shows how to use the SDK in order to read and write PSD files. The full feature set described is on the reading side, so editing and saving a layered document is not what the library is built for. ### How do I run the psd_sdk sample application on macOS? Under Xcode you need to edit the current scheme's working directory and set it to the build/Xcode directory inside your checkout so the utility can find the supplied PSD file. From the command line, copy the binary into build/Xcode and execute it from there. ## Sources - [Issues](https://github.com/MolecularMatters/psd_sdk/issues) - [License: BSD-2-Clause](https://github.com/MolecularMatters/psd_sdk/blob/master/LICENSE) - [MolecularMatters/psd_sdk on GitHub](https://github.com/MolecularMatters/psd_sdk) - [Project website](https://molecular-matters.com/products_psd_sdk.html) - [README](https://github.com/MolecularMatters/psd_sdk/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/molecularmatters-psd-sdk