# Pineapple Pictures: a lightweight Qt image viewer for odd formats

> Pineapple Pictures is a cross platform C++ image viewer built on Qt, which opens JPEG, PNG, GIF, SVG, PSD, KRA, XCF, TGA, HDR and AVIF, adds a stay-on-top mode for pinning a reference image, and reads EXIF metadata through libexiv2 when it is available. It is MIT licensed and packaged for Windows, macOS, Linux, Flatpak, the AUR, itch.io and the Microsoft Store.

**BLumia/pineapple-pictures** — A homebrew lightweight image viewer.

- Repository: https://github.com/BLumia/pineapple-pictures
- Website: https://link.blumia.net/pineapple-pictures
- Stars: 558 · Forks: 63
- Language: C++
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/blumia-pineapple-pictures

## What the viewer does and who it is for

Pineapple Pictures is a lightweight image viewer, and the README opens with the honest summary that it is yet another image viewer.

What it actually does is stated plainly. It allows you to view JPEG, PNG, GIF, SVG, PSD, KRA, XCF, TGA, HDR, AVIF and some other frequently used image formats quickly and easily, and it provides a Stay-on-Top window setting that allows you to pin the window so you can use it to pin a reference image at the top and then work with other software.

That last feature is the one that makes it different from a generic viewer. The formats list is the other one. PSD, KRA and XCF are the Adobe Photoshop, Krita and GIMP working formats, so this is a viewer aimed at people whose images arrive from a design tool rather than from a camera, and the stay on top mode is the one for a designer comparing a mockup against a build.

The README is a project page rather than a manual, and it is organised around getting the binary, since the project is distributed widely. The homepage is at link.blumia.net/pineapple-pictures, and the topics list cross-platform, image-viewer, lightweight, photo-viewer and qt, which is a fair summary of the scope.

## Where you can get a build, and who maintains them

The distribution list is long, and it distinguishes between builds the original author maintains and those that contributors and distribution maintainers carry.

Under the author's own maintenance, the GitHub Release Page is the primary source, alongside SourceForge, the Archlinux AUR with both a released package and a -git package, the Itch.io Store and the Microsoft Store. There is also a Flatpak on FlatHub under the identifier net.blumia.pineapple-pictures, and the documentation links a page on container based packaging support for people deciding whether to use the Flatpak version.

Under the other heading, contributors and certain distribution package maintainers, there is a repology packaging status badge, which is the standard way to see how many distributions carry the project.

That split is the practical fact about the project. The author's own builds are the ones you can count on for the current release, and the distro packages may lag or may carry local patches.

There is continuous integration for the three main platforms, with separate workflows and badges for the Windows build, the macOS build and the Ubuntu build, so the cross-platform claim is checked rather than asserted.

The project also accepts contributions beyond code and feedback, with translation handled on Weblate, and it takes funding through ko-fi and Afdian.

## Building it from source with CMake and Qt

The manual build needs three things. The cmake build system, qt6 with qt6-svg and qt6-tools, since the app is using Qt, and libexiv2, which is able to display more image metadata, and which the documentation marks as optional but recommended.

Then it can be built with any proper C++ compiler like g++ or msvc, and the build itself is the normal CMake sequence:

``` bash
$ mkdir build && cd build
$ cmake ..
$ cmake --build . # or simply using `make` if you are using Makefile as the cmake generator.
```

After that a ppic executable file will be available to use. You can also optionally install it by using the target install, or simply make install in case you are using Makefile, and after the build process you can also use cpack to make a package.

The exiv2 integration has a specific switch. The project will try to build with exiv2 when it is available at build time, and if you would like to build the project without exiv2 you pass -DEXIV2_METADATA_SUPPORT=OFF to cmake. The EXIV2_METADATA_SUPPORT option can also be useful if you have exiv2 but specifically do not want to use it.

One path is explicitly closed off. There is a pineapple-pictures.pro file which can be used for a QMake build, but it is only for testing purposes and it does not have exiv2 support included, and the documentation states that using QMake to build this project is NOT supported, with the advice to use CMake if possible.

## Image format support comes from the Qt plugins

The design decision worth understanding is where the format support actually comes from.

Image format support relies on Qt's imageformats plugins, and the documentation says to get the plugins you need from your distribution's package manager. That is a deliberate delegation. Instead of bundling decoders for PSD, KRA, XCF, TGA, HDR and AVIF, the viewer relies on whatever the platform's Qt installation already provides, which is why the list of supported formats is described as those formats plus some other frequently used image formats rather than a closed list.

The consequence is a platform difference you have to handle yourself. For Windows users, you may need to build and install the imageformats plugin manually, and the documentation points at content below for that. On Linux and macOS, the plugin is usually part of the distribution's Qt packages.

The metadata side is the same kind of delegation. libexiv2 gives the viewer the ability to display more image metadata, but it is optional, so the built binary will show more or less depending on whether exiv2 was present at build time, and you can force either answer with the EXIV2_METADATA_SUPPORT option.

The platform reach follows from the toolkit. It is possible to build it under Windows, Linux, macOS, and maybe other desktop platforms that Qt is ported to, and the documentation points at a wiki page for platform specific build instructions.

The tree reflects a Qt application. There is an app/ directory with the sources, an assets/ directory, a dist/ directory for packaging, CMakeLists.txt, a pineapple-pictures.pro for the unsupported QMake path, a REUSE.toml, a LICENSES/ directory, a NEWS file, an appveyor.yml, and a README.zh_CN.md alongside the main README.

## Where Pineapple Pictures is the wrong choice

The first limit is that this is a viewer and not an editor, and the documentation is explicit that the formats it opens are the ones a design tool exports. There is no mention of colour management, no RAW development, no adjustment tools and no annotation, so a photographer's workflow or a proofing workflow is out of scope.

The second is the format support, and it is a runtime question rather than a build one. Because the decoders come from the Qt imageformats plugins, what you can open depends on which plugins your platform's Qt installation ships, and the documentation's own advice is to get the plugins you need from your distribution's package manager. On Windows the documentation says you may need to build and install the plugin manually, which is a step between a user and a working format.

The third is that the EXIF metadata support is optional, so the same source tree produces two different binaries depending on the build machine, and there is no user-facing setting to change it afterwards. If reading camera metadata is a requirement rather than a nicety, that requirement is now a build configuration decision.

The fourth is packaging. There is a Flatpak, a set of distribution packages, store listings and source builds, and they will not be in step with each other. The container based packaging page is linked specifically because people are unsure which to use, and a Flatpak carries its own Qt with its own plugin set, which interacts with the previous point.

Compare that with a general purpose image viewer built on a different toolkit, or with opening the file in a browser. The difference in approach is that this project bets on Qt's plugin ecosystem and keeps its own code small, which gives you a fast binary and a wide format list, and costs you a per-platform plugin story in the documentation. If your files are all in one format, the plugin problem does not apply and this is a good default. If your format support varies by machine, that is the thing to test before you rely on it.

## Licence, releases and what to check before you install it

Pineapple Pictures as a whole is licensed under the MIT license, with individual files possibly having a different but compatible license. That second clause is the one to read carefully, because the tree has a REUSE.toml and a LICENSES/ directory, which is the standard way a project records per-file licensing for its own files and any vendored ones. The LICENSE file at the root is the starting point, and you should read it yourself for the exact terms.

The release history is regular. v1.4.1 came on 2026-04-05, v1.5.0 on 2026-07-03 and v1.6.0 on 2026-08-21, and the repository is not archived with the last push on 2026-10-22, so the tree is fresh as of today. The NEWS file in the tree is where the change notes live, since the project does not use a separate changelog file.

What to check before you install it is short. Open the two or three file types you actually care about in the build you are considering, because the format support lives in the Qt plugins rather than in this project, and that is where the surprises will be. If you care about EXIF metadata, install a build that has exiv2, and if you are on Windows, expect to install the imageformats plugin yourself.

Then decide on the packaging route, and the choice is between the author's own builds, the Flatpak, a distribution package, and compiling. The author's builds are the ones to start with, and the container page linked in the documentation is the place to read before choosing the Flatpak, because a containerised Qt brings its own plugin set with it.

If you are going to build from source, follow the CMake path and not the QMake file, since the documentation states that the QMake build is not supported, and keep the exiv2 decision explicit with EXIV2_METADATA_SUPPORT so that the binary you produce is the binary you intended.

## Conclusion

Pineapple Pictures fits someone who opens a mixed pile of design and web exports, needs PSD, KRA or XCF to render at all, and wants a viewer that starts instantly without a browser or an image editor. It does not fit a workflow that needs colour management, RAW development or annotation, since the documentation says nothing about any of those, and the format support is delegated to the Qt imageformats plugins. Before you adopt it, check that the formats you actually open are covered by the plugins on your distribution, decide whether EXIF metadata display matters to you since libexiv2 is optional, and read the platform specific build instructions if you are compiling rather than installing a package.

## FAQ

### What image formats does Pineapple Pictures open?

The summary lists JPEG, PNG, GIF, SVG, PSD, KRA, XCF, TGA, HDR and AVIF along with some other frequently used image formats, and it also provides a Stay-on-Top window setting for pinning a reference image while you work with other software. Format support relies on Qt's imageformats plugins.

### How do I build Pineapple Pictures from source?

You need cmake, qt6 with qt6-svg and qt6-tools, and optionally libexiv2 for more image metadata. The build is the normal CMake sequence: mkdir build && cd build, cmake .., then cmake --build ., which produces a ppic executable. The QMake project file exists for testing but is not supported.

### How do I disable EXIF metadata support in Pineapple Pictures?

Pass -DEXIV2_METADATA_SUPPORT=OFF to cmake. The project tries to build with exiv2 when it is available at build time, so the option is useful either when you do not have exiv2 installed or when you have it but do not want it used.

### Where can I get Pineapple Pictures for Windows, macOS and Linux?

The author's own builds are on the GitHub Release Page and SourceForge, with an Archlinux AUR package, a listing on itch.io, a Microsoft Store entry, and a Flatpak on FlatHub as net.blumia.pineapple-pictures. Contributor and distribution maintainers also carry packages, which the repology badge tracks.

### What licence applies to Pineapple Pictures?

Pineapple Pictures as a whole is licensed under the MIT license, and individual files may have a different but compatible license, with the per-file detail recorded through REUSE.toml and the LICENSES directory. The current release is 1.6.0 from 2026-08-21 and the last push was on 2026-10-22.

## Sources

- [BLumia/pineapple-pictures on GitHub](https://github.com/BLumia/pineapple-pictures)
- [License: MIT](https://github.com/BLumia/pineapple-pictures/blob/master/LICENSE)
- [Project website](https://link.blumia.net/pineapple-pictures)
- [README](https://github.com/BLumia/pineapple-pictures/blob/master/README.md)
- [Releases](https://github.com/BLumia/pineapple-pictures/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/blumia-pineapple-pictures