Initializing... drag & drop files here
Supports: X3F
X3F is Sigma's RAW format, the container written by Foveon-sensor bodies — the SD and DP lines, the Merrill generation and the Quattro cameras. (Sigma's later Bayer-sensor fp bodies write DNG instead, so those files do not belong on this page.) APNG is an animated still-image format that keeps full colour losslessly. Put those together and this page does one specific job: it takes X3F frames, renders each one, and assembles them into a single looping PNG you can post or embed without Sigma Photo Pro on the other end. Files upload over an encrypted connection, are processed on our servers, and are deleted automatically after a few hours — no sign-up, no watermark.
| Property | Value |
|---|---|
| Full name | Sigma X3F, the RAW format for Foveon X3 sensors |
| Vendor | Sigma Corporation |
| Sensor design | Stacked photodiodes recording colour at three depths, rather than a Bayer mosaic |
| Resolution quoting | Sigma counts photosites across all three layers, so the headline megapixel figure is not the rendered pixel dimension |
| Decoding here | Open-source RAW decoding — Sigma Photo Pro is not required |
| Known limits | LibRaw's supported-camera list marks the early SD9, SD10, SD14 and SD15 bodies as raw-decode-only, so those files are less predictable than Merrill and Quattro output |
| Bit depth | High-bit-depth RAW, rendered to 8 bits per channel for APNG |
| Natural targets | APNG or GIF for a loop, TIFF for an editable master, PNG for a single still |
.x3f input is accepted here. Upload order is playback order, so add a bracketed set, a focus-stack run or a timelapse in the sequence you want it to run.| What you upload | Result | Why it behaves this way |
|---|---|---|
A single .x3f |
A valid but still PNG image — it will not animate | A lone frame is not a sequence, so the assembler writes a plain lossless PNG |
Two or more .x3f, Combine? = Single animation |
One animated APNG, frames in upload order | This is the animation maker |
Two or more .x3f, Combine? = Individual files |
One output file per input | Batch conversion, not assembly |
| Frames of different sizes | Scaled and centred onto one shared canvas | An APNG requires every frame to share the same dimensions |
Before assembly, each rendered frame is normalised to a PNG capped at 4,096 pixels on its long edge, so a full-resolution Sigma file is scaled down whether or not you set a resolution yourself. That ceiling is a practical benefit here: it stops a handful of RAW frames from becoming a hundred-megabyte animation.
No. The X3F is decoded on our servers with an open-source RAW pipeline, so nothing needs to be installed on your side. Sigma's own software still renders Foveon colour differently from any third-party decoder, and LibRaw's published camera list flags the early SD9, SD10, SD14 and SD15 bodies as raw-decode-only — so if a frame from one of those cameras comes back with a colour cast, render it in Sigma Photo Pro first, export PNGs, and assemble those with PNG to APNG.
Because a single image is a single frame. The assembler collapses it and writes an ordinary static PNG under the .apng name: fully valid, transparency intact, but no animation chunks. Add at least two X3F files with Combine? set to Single animation to get something that actually loops.
The pixel detail does, up to the resolution you end up with; the RAW latitude does not. Each X3F is demosaiced and rendered to an 8-bit-per-channel sRGB frame before assembly, and every frame is capped at 4,096 pixels on the long edge, so the highlight and shadow headroom that made you shoot RAW is baked in at that point. APNG itself adds no further loss — it stores those rendered frames without re-compressing them lossily. Keep the X3F as your negative and export X3F to TIFF when you need an editable master.
Because GIF quantises every frame to 256 colours. On skies, skin and any smooth gradient — exactly the tonal transitions a Foveon sensor is bought for — that shows as banding or dithering noise. APNG stores each frame in full colour with lossless compression, so the frame you see is the frame that was rendered. The cost is size: expect an APNG to be substantially larger than the equivalent GIF.
Larger than you expect, because size scales with pixels multiplied by frames and nothing is thrown away. A ten-frame sequence at a couple of thousand pixels wide will run to megabytes. The two controls that actually move the needle are Image Resolution and the number of frames you upload; the Framerate changes the playback speed, not the byte count, once the frames are fixed.
APNG carries a full 8-bit alpha channel and this pipeline preserves alpha wherever the source has it. A camera RAW does not — a Foveon capture is fully opaque — so in practice every frame here is solid. Transparency becomes relevant only if you render your frames elsewhere with a cut-out background and bring those in as PNGs instead.
Chrome from version 59, Firefox from version 3, Safari from version 8, Edge from version 79 and Opera from version 46, which caniuse puts at about 95.94% of global traffic. Anything that does not support the animation, including a lot of desktop image software, falls back to showing the still image — that behaviour is written into the W3C PNG Third Edition Recommendation of 24 June 2025, which folded APNG into the PNG standard as section 4.9.
Yes, through the Framerate dropdown, which sets an exact per-frame delay of 1/N second for every frame. 1 FPS (Slideshow) holds each shot for a full second, 2 FPS for half a second, 10 FPS for a tenth. There is no per-frame timing control — every frame in the animation gets the same delay.