Initializing... drag & drop files here
Supports: MXF
You have a broadcast or camera .mxf and something downstream wants a Windows bitmap — a machine-vision rig, an embedded display driver, a forensic checkpoint, a printer utility, or a piece of Windows software old enough that BMP is the only image format it trusts. This page pulls one frame (or a run of frames) out of the MXF and writes it as .bmp.
Two things decide whether the result is useful, and neither is obvious from the interface. The frame you get by default is the first one, which on a professional master is very often colour bars or a slate rather than picture. And the Quality Preset is not a compression slider — on a BMP target it picks between three genuinely different bitmap encodings, one of which is not 24-bit colour at all.
.mxf onto the page or click "Add Files" to browse. Several clips can be queued and all of them use the same frame and quality settings.12 or 2.100. "Multiple Screenshots" instead samples the whole clip at a Capture Rate and writes one BMP per captured frame, with "1 second per frame" as its starting rate.The frame grab is a two-stage job. The picture comes out of the MXF first as a lossless PNG, and that PNG is then encoded into the bitmap you asked for. So the decode itself is exact — every question about how the still looks is a question about the preset you chose, not about the MXF being read badly.
On the frame itself, the Time (seconds) default of 0 is the single most common source of a disappointing result. Broadcast deliverables and playout exports open with bars and tone, a countdown, a slate or a few seconds of black by convention, so t=0 on a station master reliably returns a test pattern. Scrub the clip in whatever will open it, note a timestamp inside the programme, and type that number instead. The field accepts decimals, so 90.5 is a second and a half past the minute-and-a-half mark.
"Multiple Screenshots" is the mode to reach for when you do not know which frame you want yet — but do the arithmetic before you run a long master through it. At the starting rate of one frame per second, a forty-minute rush produces 2,400 uncompressed bitmaps. Step the Capture Rate down to one frame every five or ten seconds, or trim the clip first.
BMP has no quality slider in the JPEG sense — there is nothing to trade off, because the format stores pixels literally. What the preset actually selects is the bitmap encoding:
| Preset | Bitmap written | Colours | Size behaviour |
|---|---|---|---|
| High | Uncompressed, 16 bits per pixel in RGB 555 layout | 32,768 | Fixed and predictable: two bytes per pixel plus header and row padding |
| Medium | 8-bit palette bitmap, RLE-compressed, written in the classic BMP3 header form, with Floyd-Steinberg dithering and a light selective blur | 256 | Much smaller; depends on how flat the picture is |
| Low | 8-bit palette bitmap, RLE-compressed, Floyd-Steinberg dithering, tagged at 150 pixels per centimetre | 86 | Smallest, and visibly dithered on photographic content |
Note that High is not 24-bit truecolour — it is the 16-bit RGB 555 layout, five bits each for red, green and blue. Microsoft's BITMAPINFOHEADER reference documents both halves of what that implies: at 16 bits per pixel with BI_RGB the format is always RGB 555, and the minimum row stride is the width in bytes rounded up to the nearest four-byte boundary. That makes an uncompressed bitmap's size arithmetic rather than a guess. A 720 x 576 broadcast frame at High comes to 829,494 bytes — exactly two bytes for every one of the 414,720 pixels, plus the 54-byte header.
One practical warning: the preset that is pre-selected on other image targets is one of the entries BMP hides, so do not assume the box already holds a sensible value. Open the list and pick High, Medium or Low deliberately.
| Property of the master | Effect on the BMP |
|---|---|
| Interlaced (1080i, 576i) | Both fields land in the grab, so anything moving shows comb lines. Nothing in this pipeline deinterlaces |
| Non-square pixels (1440x1080, 720x576 flagged 16:9) | The raster is written as stored, not stretched to its display shape, so people look narrow |
| Log or HDR grading (S-Log, HLG, PQ) | Colour-converted plainly with no tone-mapping stage, so it reads flat and washed out |
| Several audio tracks | Discarded — a bitmap has no sound |
| Timecode, reel name, essence metadata | Discarded — the BMP header stores dimensions, bit depth and pixel density and nothing else |
| OP-Atom split essence (Avid, P2) | If the file you upload holds only the audio track, there is no picture to grab |
Because a bitmap stores every pixel literally while the video stores an approximation of many frames at once. On the High preset the arithmetic is fixed: two bytes per pixel plus a 54-byte header and row padding to four-byte boundaries. A 1920 x 1080 frame is therefore about 4 MB and a 3840 x 2160 frame about 16.6 MB, whatever the picture contains. Medium and Low cut that by dropping to an 8-bit palette and run-length encoding the result, which on flat graphics is dramatic and on grainy footage is much less so.
No, and this catches people out. High writes an uncompressed 16-bits-per-pixel bitmap in the RGB 555 layout — five bits each for red, green and blue, giving 32,768 possible colours. It is the highest-fidelity option this page offers and it is genuinely uncompressed, but it is not the 24-bit truecolour bitmap you may be picturing. If a downstream tool specifically requires 24-bit BMP, or if you need every one of the master's colour values, take the frame as MXF to PNG instead and convert it onward in a tool that lets you set the bit depth.
Both write an RLE-compressed palette bitmap with Floyd-Steinberg dithering, which spreads quantisation error into neighbouring pixels so that banding reads as fine noise rather than hard steps. Medium keeps 256 colours, writes the classic BMP3 header form and applies a light selective blur before quantising, which helps flat graphics quantise cleanly. Low drops to 86 colours and tags the file at 150 pixels per centimetre. Low is the smallest and the most visibly dithered; on photographic broadcast content the difference between them is easy to see.
Because Frame Selection opens on "Specific Frame" with Time (seconds) set to 0, and the first frame of a professional master is very often not programme content. Bars and tone, countdown leaders, slates and black at the head are standard on broadcast deliverables. Type a timestamp from inside the programme — the field takes plain seconds with an optional decimal, so 65.5 and 2.100 are both valid — and the grab will land where you meant it to.
You can sample the clip, but not at full frame rate, and you almost certainly do not want to. "Multiple Screenshots" walks the file at the Capture Rate you choose, from one frame every ten seconds up to ten frames per second, writing one bitmap per sample. Even at the fastest available rate that is not every frame of a 25 or 50 fps master, and at uncompressed sizes a full-rate dump of a feature-length clip would run to hundreds of gigabytes. If you genuinely need dense frame extraction, use a slower rate and trim to the section that matters.
The decode is exact — the frame is pulled out as a lossless PNG before anything else happens — so no sharpness is lost in reading the file. What you lose is colour resolution at the encoding step, and only that: 32,768 colours on High, 256 on Medium, 86 on Low. Geometry, detail and edge definition are untouched unless you also resize. If you want the frame with nothing given up at all, MXF to PNG writes true-colour lossless.
Because the essence is anamorphic and the pipeline writes the stored raster rather than the display shape. Broadcast SD and HD material routinely stores a 16:9 picture in a 720x576 or 1440x1080 grid with non-square pixels, relying on the player to stretch it at display time. A bitmap has no pixel-aspect field that the receiving software will honour, so the fix is to set it explicitly: Image resolution to Width x Height, typing the display dimensions you want, such as 1024x576 or 1920x1080.
MXF is a professional interchange container, and consumer players generally ship neither the demuxer nor the essence decoders that broadcast files need — XDCAM's MPEG-2 422P@HL, AVC-Intra, DNxHD and similar. The decoding here happens on our servers with a build that carries those decoders, which is why a clip that refuses to open on your desktop still yields a frame. Files that still fail are usually partial card offloads, interrupted recordings or vendor-specific variants; re-exporting a flat OP-1a master from your editor fixes almost all of them.
Your MXF uploads over an encrypted connection, is processed on our servers, and is deleted automatically after a few hours along with every still it produced. There is no sign-up, no watermark, and nothing is shared or made public. Because a broadcast master can run to many gigabytes and you may only want one frame from it, cutting the clip down first with trim MXF is usually far quicker than uploading the whole thing.