MTS to TIFF Converter

MTS to TIFF Converter

An .mts file is AVCHD camcorder footage: MPEG-4 AVC/H.264 video written by a Sony or Panasonic handycam, carrying Dolby Digital (AC-3) or linear PCM audio, at up to 24 Mbps for the standard recording modes. A .tiff file is a single still image in Tagged Image File Format. This page decodes one frame out of the video and writes it as TIFF — ffmpeg seeks to the timestamp you name and hands the raw frame to the image writer.

TIFF gets chosen for this job because of what the specification permits rather than what any one file contains, and that distinction causes most of the confusion around it. The reference tables below cover what the format actually guarantees, and — separately — which of those capabilities this particular conversion path exposes.

TIFF Format at a Glance

That "compression is selected per image" row is the one worth dwelling on. TIFF is a container, not a compression method, so a TIFF file can hold uncompressed data, LZW-coded data, or JPEG-coded data with equal validity. The widespread belief that TIFF means lossless is a convention, not a rule — and it is not the convention this page follows by default.

What This Conversion Path Actually Produces

How to Convert MTS to TIFF

1. Upload Your MTS File: Drag the .mts clip onto the page or click "Add Files". Several clips can queue and each returns its own still.
2. Set Frame Selection and the Timestamp: Frame Selection opens on "Specific Frame" with Time (seconds) at 0. Enter the moment you want — decimals are accepted — or switch to "Multiple Screenshots" and choose a Capture Rate.
3. Set Compression Type and Image Resolution: Compression Type opens on JPEG, which is lossy; choose LZW or DEFLATE if the file needs to be lossless. Image resolution opens on "Keep original".
4. Convert and Download: Click Convert and save the .tiff. Files upload over an encrypted connection, are processed on our servers, and are deleted automatically after a few hours — no sign-up, no watermark.

Two Format-Level Caveats for AVCHD Sources

TIFF preserves whatever it is given, which cuts both ways when the source is camcorder video. AVCHD is interlaced in most camera modes — the format specification lists 1080i alongside the progressive modes, and on many camcorders 1080i is the only option available. A frame woven from two fields captured moments apart carries comb teeth on anything that moved, and no stage of this conversion deinterlaces. A lossless TIFF records those teeth with the same fidelity it records everything else.

The second caveat is geometry. AVCHD's frame sizes include 1440x1080 as well as 1920x1080, and the 1440-wide modes store non-square pixels that a player stretches on screen. Our resize step normalises to square pixels, so scaling one of those frames by percentage or by a height preset produces a picture that is correctly detailed but wrongly shaped. Use Width x Height and enter both dimensions explicitly. If your clip has already been renamed .m2ts by import software, this page will refuse it — the video to TIFF extractor accepts both spellings of the same stream.

Frequently Asked Questions

Does a TIFF file have to be lossless?

No, and this is the most consequential misunderstanding about the format. TIFF Revision 6.0 defines a container in which each image declares its own compression scheme through a tag; uncompressed, LZW, Deflate, PackBits, Group 4 fax and JPEG are all legitimate TIFF. A JPEG-compressed TIFF is not malformed or unusual, it is simply lossy. On this page JPEG happens to be the pre-selected Compression Type, so a file converted without changing it is a valid TIFF containing lossy image data. Set Compression Type to LZW when lossless is what you actually need.

Which TIFF revision does this write, and will older software open it?

Classic TIFF as described by Revision 6.0 — the version word is 42, not the 43 that marks a BigTIFF — written through libtiff, which is the implementation most applications read TIFF with. Compatibility therefore depends far more on your compression choice than on the revision. LZW, PackBits and uncompressed are read essentially everywhere. Deflate is very widely supported. ZSTD and WebP inside TIFF are recent codec extensions and need a current libtiff-based reader, which is why they are poor choices for anything you expect to open in a decade.

Can I get one TIFF that holds every frame of the clip?

Not from this page. The specification does support it — a TIFF file contains one or more subfiles, each with its own Image File Directory, which is how multi-page scans work — but our conversion writes one image per file. "Multiple Screenshots" walks the clip at your chosen Capture Rate and returns each frame as an individual TIFF. It is worth noting that baseline TIFF readers are only required to use the first subfile anyway, so multi-page TIFFs are less portable than they appear.

Is there a file-size ceiling I could run into?

Classic TIFF is limited to 4 GB because it addresses data with 32-bit offsets, which is the constraint BigTIFF was created to lift by moving to 64-bit offsets. In practice you will never approach it here: a single uncompressed 1920x1080 RGB frame is around six megabytes, so the limit only becomes relevant for very large multi-page scans or gigapixel imagery, neither of which this path produces. The realistic constraint on this page is upload size, since the whole AVCHD clip travels before one frame is decoded from it.

Does the TIFF carry an ICC profile, EXIF data or the recording date?

No, and the reason is the source rather than the format. TIFF is perfectly capable of holding an ICC profile and EXIF-style tags — the Exif specification is itself built on TIFF structures — but a frame decoded out of a video stream has no camera EXIF block to inherit and no embedded display profile travelling with it. What you get is pixel data with structural tags. If the capture date matters to your catalogue, read it from the original .mts and record it alongside the still.

Why is there no DPI or bit-depth setting on this page?

Because neither control renders on this conversion path — we checked the option surface for this page rather than inferring it from what TIFF permits. DPI is a metadata tag that describes intended print size, not image data, so its absence changes nothing about the pixels you receive; a print shop can set the resolution tag at their end, or you can set it in any image editor without re-encoding. Bit depth is likewise fixed here. The controls that do render are Compression Type, Quality Preset, Image resolution, the File extension choice and Frame Selection.

Does the TIFF have an alpha channel?

No. TIFF supports RGBA and the specification accommodates transparency, but video cannot store an alpha channel in the first place, so a frame decoded from AVCHD is fully opaque and is written as plain RGB. There is one related trap worth knowing: JPEG compression inside TIFF cannot represent transparency at all, so on sources that do have alpha the pre-selected JPEG setting flattens it to black. That is not a factor here, but it is another reason LZW is the safer default habit.

Will a TIFF written here open on both Windows and macOS?

Yes. The two-byte marker at the start of every TIFF declares its byte order — II for little-endian, MM for big-endian — precisely so that readers on either architecture can interpret the file correctly, and every mainstream TIFF reader handles both. The historical Mac-versus-PC TIFF friction was never really about byte order; it was about applications that only implemented a subset of compression schemes. Staying on LZW or uncompressed removes that risk entirely. For an image that opens on phones and in browsers too, MTS to JPG or MTS to PNG is the more practical target.