Initializing... drag & drop files here
Supports: RW2
.rw2 is the raw file a Panasonic LUMIX body writes — 12- or 14-bit sensor readings with no white balance, tone curve or sharpening applied to the pixels yet. .ts is the MPEG-2 transport stream from ISO/IEC 13818-1, the broadcast container that chops media into fixed 188-byte packets so a corrupted packet costs a fraction of a second rather than the whole file.
Those two things have nothing to do with each other, and the conversion is honest about it: the raw is developed into one finished frame, and that frame is held on screen inside a transport stream for as long as you ask. The result is a silent, motionless clip. That is genuinely what you want for a slate, an ident, a test card or a hold frame going into a playout system, an IPTV encoder or an HLS-era segmenter that ingests .ts. For anything else — a picture to look at, a file to send someone — RW2 to JPG is the page you actually want, and RW2 to MP4 is the one for a clip that plays on ordinary devices.
.rw2 onto the page or click "+ Add Files" to browse — straight off a LUMIX G, GH, S or LX body. Several frames can be queued at once..ts per frame). Image Duration runs from a single frame at 60 fps up to 10 seconds per frame, with 5 seconds preselected..ts. Files are uploaded over an encrypted connection, developed and packetised on our servers, and deleted automatically after a few hours — no sign-up, no watermark, never shared or made public.The raw is developed, and that is one-way. An .rw2 holds mosaic sensor data with real latitude — highlights to pull back, white balance to shift, exposure to push. To be encoded at all it has to be demosaiced into ordinary RGB, and the render bakes in the camera's own recorded white balance to produce an 8-bit sRGB frame. Once that frame is inside the transport stream the latitude is gone exactly as it would be in a JPEG. A LUMIX Photo Style is a rendering instruction Panasonic's own software applies, not data a third-party renderer can reproduce, so if the look matters, develop and export first and convert the export. Keep the .rw2 as the master either way.
The frame is not your sensor resolution. Before encoding, every image is normalised and clamped to 4096 pixels on the long edge, with both dimensions rounded to even numbers. That is a much bigger cut than most people expect from a modern LUMIX:
| Developed frame | What reaches the encoder | Linear reduction |
|---|---|---|
| 4096 px long edge or smaller | Unchanged | none |
| 4736 x 3552 (17 MP, 4:3) | 4096 x 3072 | 13% |
| 5208 x 3904 (20 MP, 4:3) | 4096 x 3070 | 21% |
| 8368 x 5584 (47 MP, 3:2) | 4096 x 2732 | 51% |
Aspect ratio is preserved and nothing is cropped — but on "Keep original" that clamped size is what the .ts gets, and a 4096-pixel-wide H.264 stream is legal while being well outside what transport-stream hardware expects to be handed.
The clip is a held still at 1 frame per second, and it is silent. B-frames are disabled and the same picture is repeated, so a 5-second duration is five identical frames rather than motion. There is no audio track and no Audio Codec control, because a photograph has no sound to carry.
There are two resolution lists on this page and they do not behave the same way. This catches people out constantly:
| Control | What it sets | A 4:3 LUMIX frame at "1080p" | Use it when |
|---|---|---|---|
| Keep original | The clamped render size | 4096 x 3070 | You want maximum detail and nothing downstream cares |
| Fixed Resolutions | An exact width-by-height pair | 1920 x 1080 exactly | Anything going into a broadcast, IPTV or playout chain |
| Preset Resolutions | Height only — width follows the source aspect | 1441 x 1080 | You want a target height and do not care about the width |
For a .ts that has to land in a real chain, use Fixed Resolutions and take 1920 x 1080 from the list. A 4:3 photograph placed in a 16:9 frame leaves bars on both sides, and those bars are filled with the Background Color rather than cropped away — so change it from White to Black, or to a brand colour, before you convert.
One more thing worth knowing about the codec choice: because H.264 supports CRF, the Quality Preset on this page genuinely maps to a quality number rather than doing nothing. Very High (Recommended) is preselected, which is CRF 18 at a 1080p-sized frame, nudged up by up to two points at much larger frame sizes because dense pixels hide artefacts. On a motionless frame the encode is cheap at any rung, and resolution dominates the result: encoding the same picture for five seconds at CRF 23, we measured 6.4 MB at 4096 x 3070 against 898 KB at 1920 x 1080.
Neither. The raw is developed into a single frame, that frame is repeated at one frame per second for the duration you set, and B-frames are off — so it plays as a freeze. It is silent because a photograph has no audio track, which is also why no Audio Codec control appears for image sources. Uploading several RW2 files with "Merge images" joins them back to back, each held in turn; that is a run of stills, not a slideshow with transitions.
Because every image is clamped to 4096 pixels on its long edge before encoding, and "Keep original" means the clamped render, not the sensor. A 5208 x 3904 frame arrives at the encoder as 4096 x 3070 — aspect ratio intact, roughly 21% off the linear resolution. On a 47-megapixel body the cut is over half. If you want every pixel the sensor recorded, a video container is the wrong destination entirely: use RW2 to TIFF for a full-resolution master or RW2 to PNG for a lossless copy.
No — you used Preset Resolutions, which sets the height and lets the width follow the source aspect ratio. A 4:3 photograph at "1080p" is therefore 1441 x 1080, and a 3:2 one is 1619 x 1080. For an exact broadcast raster use Fixed Resolutions, which gives you real width-by-height pairs including 1920 x 1080, 1280 x 720 and 3840 x 2160.
Completely. An .rw2 stores undeveloped sensor data, which is why highlights, shadows and white balance stay recoverable long after the shot. Encoding requires a finished 8-bit frame, so the file is demosaiced first and the camera's recorded white balance is baked in. After that you are editing a finished photograph, exactly as with a JPEG. Keep the original .rw2 if there is any chance you will want to reinterpret the shot.
H.264, which is what the list opens on. A transport stream is codec-agnostic by design and can legally carry MPEG-2, H.264 or H.265, but H.264 is the broadest-compatibility choice for transport-stream players and the codec HLS .ts segments historically used. Switch to MPEG-2 only if you are feeding a classic DVB or ATSC chain that expects it. The MPEG-4, DivX and Xvid entries will write a valid file, but they are not what a broadcast tool expects to find inside a .ts, and unlike H.264 they get no benefit from the Quality Preset on a still image.
Because a 4:3 or 3:2 photograph does not fill a 16:9 frame, and rather than stretching or cropping the image the converter pads the difference with the Background Color — which opens on White. Letterboxed slates are perfectly normal in broadcast; a white surround usually is not. Change it to Black before converting, or crop the photograph to the output aspect ratio first.
.ts the same thing as the .mts or .m2ts files from a camcorder?They carry the same H.264 video but lay the bytes out differently, and the extension is what decides which layout you get. A plain .ts uses 188-byte packets with the sync byte 0x47 at offset 0. The BDAV variant used for disc media prefixes each packet with a 4-byte arrival timestamp for 192 bytes total — we checked identical encodes byte for byte, and the .m2ts file begins 0e with its sync byte at offset 4. On this site RW2 to MTS writes plain 188-byte packets like this page, and RW2 to M2TS writes the 192-byte BDAV framing. Renaming a file does not re-frame it, so generate the one your software checks for.
Yes. Queue the photographs and leave Merge strategy on "Merge images" — each developed frame is packetised back to back into a single transport stream in upload order, held for the Image Duration you chose, so the total length is that duration times the file count. "Video per image" instead writes one .ts per photograph, which is usually more useful in an edit because each still can then be trimmed and placed independently. Neither mode adds motion, transitions or audio.
Usually you would not. The narrow cases where a transport stream is genuinely correct are feeding a still as a slate or test card into a DVB or ATSC playout system, an IPTV encoder, or an older HLS pipeline that segments into .ts, and satisfying a capture or set-top tool that reads only the standard 188-byte stream. For anything you intend to look at, RW2 to JPG gives you a picture and RW2 to MP4 gives you a clip that plays on phones, browsers and TVs without ceremony.
It is uploaded over an encrypted connection, developed and packaged into the transport stream on our servers, and deleted automatically after a few hours along with the clip it produced. There is no sign-up, no watermark, and nothing is shared or made public. LUMIX raws run to tens of megabytes each while a motionless H.264 frame compresses very heavily, so the upload rather than the encode is what you will spend time waiting on — convert in modest batches rather than one long queue.