LZW compression expands files

[spoutn1k]

I do photography on the side. I always ask for scans in TIFF format and always get scans in uncompressed TIFF formats. Because I value my disk space, I use magick to compress the TIFFs using LZW and get 15-20% of the file size back.

I have been trying to use this crate to do just that. This is the code I used:

fn compress(tif: &std::path::Path) -> Result<(), Box<dyn Error>> {
    let photo = ImageReader::open(tif)?.with_guessed_format()?.decode()?;

    let compressed = std::fs::OpenOptions::new()
        .write(true)
        .create(true)
        .open(tif.with_extension("tiff"))?;

    let mut encoder =
        tiff::encoder::TiffEncoder::<std::fs::File, tiff::encoder::TiffKindStandard>::new_generic(
            compressed,
        )?;

    encoder.write_image_with_compression::<tiff::encoder::colortype::RGB8, tiff::encoder::compression::Lzw>(
        photo.width(),
        photo.height(),
        tiff::encoder::compression::Lzw,
        photo.as_bytes(),
    )?;

    Ok(())
}

(This is a quick and dirty attempt and the input files come as .tif, so no conflicts when I use the .tiff extension)

Now this script produces compressed TIFF files BIGGER than uncompressed originals. Is this not crazy ?

103701jean_003126> ll                                                                                                                     
total 181M
drwxr-xr-x   5 jb staff  160 Jul 30 21:22 .
drwx------+ 49 jb staff 1.6K Jul 30 21:22 ..
-rw-r--r--   1 jb staff  67M Jul 30 21:22 02.lzwtiff
-rw-r--r--   1 jb staff  57M Jul 26 15:47 02.tif
-rw-r--r--   1 jb staff  44M Jul 30 21:36 02.tiff
-rw-r--r--   1 jb staff  57M Jul 30 21:22 02.unctiff

.tif is the original. .lzwtiff was created using image-tiff and LZW compression, .unctiff was created using image-tiff and uncompressed output. The .tiff file was created using magick -compress lzw.

How is this possible ? Am I doing something wrong ?

[feefladder]

I think this issue belongs over at weezl, since they do the LZW compression?

[spoutn1k]

Nope, the compression is fine. I found out the issue is the the lack of prediction before compression. Implemented in #240.