Initializing... drag & drop files here
Supports: MTS
An .mts file is AVCHD camcorder footage — MPEG-4 AVC/H.264 video written to a Sony or Panasonic memory card. A .ppm file is a Portable Pixmap: a four-token ASCII header followed by raw RGB bytes, and nothing else. The Netpbm specification calls it a "lowest common denominator color image file format" and notes that it "allows very little information about the image besides basic color."
That is the whole reason this conversion exists. PPM is not a viewing format; it is the format you reach for when code has to read pixels with no decoder in the way — OpenCV, Pillow, ImageMagick and the Netpbm utilities all parse it in a few lines. If a person is going to look at the frame, MTS to PNG or MTS to JPG is the right target and this page is the wrong one.
| Property | Value |
|---|---|
| Full name | Portable Pixmap, part of the Netpbm family (PBM / PGM / PPM / PNM / PAM) |
| Magic number | P6 for the binary form, P3 for the plain ASCII form; we write binary |
| Header | Magic number, width, height and maxval, all as ASCII decimal |
| Bytes per sample | 1 when maxval is under 256; 2 when maxval is 256 to 65535 |
| Colour model | RGB triplets in scan order — no alpha channel |
| Compression | None of any kind |
| Metadata | None: no EXIF, no ICC profile, no capture timestamp |
| One 1920x1080 frame | About 6.2 MB at 8-bit (1920 x 1080 x 3 bytes); roughly double at 16-bit |
| Read by | OpenCV, Pillow, ImageMagick, GIMP, the Netpbm tools |
PPM is the only image target on the site that exposes a Bit Depth control, because bit depth is part of the format's own definition rather than something a codec negotiates for you. The three settings do not behave the way their labels suggest, so here is what each one puts in the file:
| Bit Depth setting | What lands in the file | Effect on size |
|---|---|---|
| 8-bit (Recommended) — pre-selected | Full 24-bit colour, one byte per sample, maxval 255 | Baseline: width x height x 3 bytes |
| 16-bit (High Precision) | maxval above 255, so the spec requires two bytes per sample | Roughly doubles the file |
| 1-bit (Black & White) | One bit of precision per channel, so eight possible colours — still stored as one byte per sample | Essentially none |
The 1-bit label is the one to be careful with. It does not produce a bilevel black-and-white bitmap, because a PPM is a three-channel pixmap and reducing each channel to a single bit leaves eight colours, not two. It does not shrink the file either: with maxval still under 256 the raw writer keeps one byte per sample regardless of how few distinct values those bytes hold. We measured this on a frame through our own pipeline — 6,155 bytes at 1-bit against 6,157 bytes at 8-bit, a two-byte difference that comes from the header, not the image. Treat it as a heavy posterisation effect, not a size or colour-mode control.
.mts clip onto the page or click "Add Files". Several clips can queue and each returns its own pixmap..ppm. Files upload over an encrypted connection, are processed on our servers, and are deleted automatically after a few hours — no sign-up, no watermark.Because PPM applies no compression, resolution is the only honest size lever you have. Halving both dimensions quarters the byte count; nothing else in the panel meaningfully changes it. A frame at 1280x720 is about 2.8 MB, at 960x540 about 1.6 MB, and the arithmetic is exact rather than content-dependent because every pixel costs the same three bytes whether it is flat sky or fine detail.
Two things specific to AVCHD sources are worth knowing before you build a pipeline on this. First, nothing in this conversion deinterlaces. Most camcorders record 1080i and on many models it is the only mode; a frame woven from two fields captured moments apart keeps its comb teeth in the pixmap, which will show up as horizontal high-frequency noise in any analysis you run downstream. Second, our resize step writes square pixels, so a 1440x1080 anamorphic AVCHD frame will come out geometrically narrow if you scale it by percentage or by a height preset — set Width x Height explicitly (1920 and 1080) to get the intended proportions. Also note that this page accepts the .mts spelling only: if your import software already renamed the clip to .m2ts, use the video to PPM extractor, which accepts both.
Code, mostly. OpenCV, Pillow, ImageMagick, GIMP and the Netpbm command-line tools all read PPM directly, which is why it survives as a pipeline format decades after anything else stopped using it. What generally will not open it is the software a normal person has: browsers do not render PPM, Windows Photos and macOS Preview are unreliable with it, and phone galleries ignore it entirely. If you needed a picture rather than a pixel buffer, you wanted MTS to PNG.
Neither, and this is the most common misunderstanding about this page. We measured the same extracted frame both ways through our pipeline: 6,155 bytes at 1-bit versus 6,157 bytes at 8-bit. The reason is in the Netpbm specification — a raw PPM stores one byte per sample whenever maxval is below 256, so cutting the precision does not cut the storage. And because a pixmap has three colour channels, one bit each leaves eight possible colours rather than two. What you get is a harsh posterisation, not a bilevel mask.
Because you traded a codec for no codec. AVCHD packs an entire second of moving 1080p into roughly 3 MB using H.264's inter-frame prediction; PPM spends about 6.2 MB on one still frame because it writes every pixel out in full. This is not a bug or a setting to fix — it is the point of the format. If the size is a problem, either scale the frame down or pick a compressed target instead.
No, on two counts. The format has nowhere to put it — the Netpbm specification is explicit that PPM carries no alpha channel and no embedded colour profile, and the header holds only dimensions and maxval. On top of that our conversion strips metadata as it writes. If provenance matters for your dataset, record the source filename and timestamp alongside the pixmaps rather than expecting them to travel inside the files.
It is an exact copy of the decoded frame, which is not the same thing. The PPM stage itself adds nothing and removes nothing: what the H.264 decoder produced is what gets written. But the camera already threw information away when it encoded the footage at up to 24 Mbps, and no amount of uncompressed storage afterwards brings that back. A PPM is a perfect record of an imperfect frame.
Usually not. Consumer AVCHD is an 8-bit format end to end, so asking for 16-bit samples doubles every file while adding no information that was not already there — the extra bits are padding derived from the same 8-bit values. Pick 16-bit only when a downstream tool genuinely requires two-byte samples as its input contract, which does happen in some scientific and medical toolchains. Otherwise 8-bit is both correct and half the size.
The specification does allow a sequence of images in one PPM stream, but that is not what we produce — each extracted frame is written as its own file. "Multiple Screenshots" walks the clip at the Capture Rate you choose and returns the frames as individual pixmaps, which is what a batch loop expects anyway. If you need them concatenated into one stream, that is a one-line cat at your end.
Because the Netpbm family puts bit depth in the file header as maxval, so it is a decision the writer has to make explicitly. PNG negotiates its own bit depth from the image content, and our TIFF path exposes a Compression Type choice instead of a depth choice. That is also why the control's behaviour here is unusual enough to need the explanation above — it is passing a precision setting down to the raster writer, not selecting a colour mode.
The .mts is uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours. Nothing is shared or made public, there is no sign-up and no watermark. To go the other way and build a clip from a sequence of pixmaps, see PPM to MTS.