0

I'm using the "Twelve Monkeys" (Github) library to read a .tif/.tiff file in Java 8, add a logo and export the new image as a new .tif/.tiff file:

try {
    BufferedImage buffLogo = ImageIO.read(fLogo);
    BufferedImage buffInput = ImageIO.read(fImg);
    int image_type = buffInput.getType();

    //Computing correct position and size of logo here...

    BufferedImage buffOutput = new BufferedImage(buffInput.getWidth(), buffInput.getHeight(), image_type);
    File out = new File(outputImg);

    Graphics2D g = buffOutput.createGraphics();
    g.drawImage(buffInput, 0,0,null);
    g.drawImage(buffLogo, pos_x,pos_y,size_x,size_y,null);
    g.dispose();

    System.out.println("Beginning to write to: '"+out.getAbsolutePath()+"'");
    long start = System.currentTimeMillis();
    ImageIO.write(buffOutput, "tif", out);
    long dur = (System.currentTimeMillis() - start) / 1000;
    System.out.println("Writing finished successfully ("+dur+"s)!");
} catch (IOException e) {
    System.out.println("Exception:\n"+e.getMessage());
}

The input files I've tested this with so far are about 12mb each, TYPE_3BYTE_BGR and use LZW compression. Exporting as .png only takes a couple of seconds and the files are slightly smaller than the originals. Jpg is even faster and each file is <1mb. If I export as .tif/.tiff, then ImageIO.write not only takes about 5 minutes to finish writing a single file but the files are also huge, about 25mb with the same type (more with e.g. TYPE_INT_ARGB but I don't need transparency).

Is that just the way the library works or is there anything specific I have to do, any specific parameters I have to set or other functions to use to make exporting tifs faster and the resulting files a lot smaller (more like the original size, edit: LZW compression would be fine)?

Neph
  • 1,823
  • 2
  • 31
  • 69
  • 3
    This is mostly speculation, but: Tiffs are a big, lossless file format. Typically they're used to store source files prior to editing, not output files. Very few people want to *output* Tiff files. At a guess I would say the size is expected, and the speed (vs png) is a combination of Tiff producing *much* larger files, and the Tiff encoder being much less optimized than the PNG encoder, due to lack of use. – user229044 Aug 23 '23 at 11:36
  • 1
    Disk I/O is slow. Compression is probably the best way to address that. I’m not sure what you mean by “extra compression”; would you consider writing a [compressed TIFF](https://docs.oracle.com/en/java/javase/20/docs/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html#Compression)? – VGR Aug 23 '23 at 15:01
  • 1
    First, I have to say that 5 minutes seems unreasonably long, for writing a 25 MB TIFF... Seems something is off... If I/O is the big bottleneck here, I would expect writing a 25 MB TIFF to take about 2x the time writing a 12 MB PNG. Please tell more about your environment, like Java version, OS, type of disk, memory etc. 5 minutes makes it sound like your process is very low on memory. – Harald K Aug 23 '23 at 15:27
  • That said, the TwelveMonkeys TIFF plugin does write uncompressed by default (for historical reasons). You could try specifying a compression, like "deflate" which should produce a size similar to that of PNG (although the TIFF "horizontal predictor" is less sophisticated than PNG's predictor, so expect slightly larger files). – Harald K Aug 23 '23 at 15:30
  • 2
    I made a small sample program, writing a 3400x2550 `TYPE_3BYTE_BGR` (~25MB) image with a gradient. The results on my 2019 MBP/i7 with decent SSD was: PNG size: 303385/time: 396ms, JPEG size: 143073/time: 125ms, TIFF uncompressed size: 26010190/time: 88ms, TIFF deflate/zlib compressed size: 686038/time: 189ms. Yes, all times in *milliseconds*. In other words... 5 minutes sounds VERY odd. – Harald K Aug 23 '23 at 17:33
  • Sorry about the delay. @user229044 I'm aware TIFF isn't used as much and that it creates larger files than e.g. png but storage isn't a problem and the people these files are for are in a field that mostly uses TIFF. I don't expect TIFF to be exported as fast as e.g. png but 5 minutes seems a bit off and I'm wondering if I missed something in Twelve Monkeys that might be obvious to others. – Neph Aug 25 '23 at 09:24
  • @VGR Sorry, my mistake. I just checked again, comparing the imported to the exported TIFF and the former uses LZW compresses, which would at least explain the size difference. Using LZW for the exported file would be okay too (haven't checked yet if that's possible with this library). The link you provided is for JDK 20, I'm using Java 8. – Neph Aug 25 '23 at 09:31
  • @HaraldK Yes, 5 minutes does seem off, looking at how fast exporting as png/jpg is, that's why I asked this question, maybe I missed something in the library that's obvious to others. I'm using: Java 8, Win 10, old Ivy Bridge Xeon, 24gb RAM, both my Java project and the images (about 2700x3400) are on the system SSD (Samsung 860 EVO). I made a mistake, the input files use LZW compression, so that one would be fine for the exported ones too. Not sure if the library supports that one (haven't checked yet). MBP? – Neph Aug 25 '23 at 09:43
  • If 5 minutes is an actual, timed number, yes, that is absurd. I assumed that was an exaggeration, similar to calling a 25 mb tiff "huge" (that's a very normal sized tiff). – user229044 Aug 25 '23 at 14:31
  • 1
    Hmmm.. Just remembered this: https://github.com/haraldk/TwelveMonkeys/issues/744... Which version of the library are you using? Perhaps upgrading will fix it... – Harald K Aug 27 '23 at 17:13
  • @user229044 I didn't time it the first couple of tries (only added that code after it took so long) but I checked the Win clock. The latest test (just now) took 322s seconds. – Neph Aug 28 '23 at 09:34
  • @HaraldK Thanks for the link! I wanted to post on their issues page first but they tell you to use Stackexchange instead, no idea how I missed that. But yes, I'm using exactly that version (3.9.4), which is the latest/only version in the "Links to prebuilt binaries" section (older versions can be found [here](https://repo1.maven.org/maven2/com/twelvemonkeys/common/common-lang/)). There are a lot of snapshot jars [here](https://oss.sonatype.org/content/repositories/snapshots/com/twelvemonkeys/common/), should I just take the latest ones (from August 25th)? Does TM support LZW compression? – Neph Aug 28 '23 at 09:44
  • I see. I just have a bit too much on my plate these days... Should make a new release soon. Try the latest 3.10.0-SNAPSHOT! And yes, LZW compression is supported, but it's probably not as fast as Deflate/ZLib. – Harald K Aug 28 '23 at 10:22

0 Answers0