ImageExporter to .png, fast versions

[mhoibo]

Hi,
I am using FAST's ImageExporter to export patches to, amongst other, .PNG. I have seen something that I found a bit strange, but might not be an issue at all. I am using a linux machine, and I have been using this python wheel for the most part. Then, extracting and saving patches, with the following code:

  path = /path/to/image/
  output_fn = /path/to/output/folder/
  level = chosen level
  patch_size = 256
  
  importer = fast.WholeSlideImageImpoerter.create(path)
  tissue_segmentation = fast.TissueSegmentation.create() \
                      .connect(importer)
  
  patch_generator = fast.PatchGenerator.create(patch_size, patch_size, level=level) \
                  .connect(0, importer) \
                  .connect(1, tissue_segmentation)
  
  for i, patch in enumerate(fast.DataStream(patch_generator)):
      fast.ImageExporter.create(filename=f'/{output_fn}patch_{i}.png') \
          .connect(patch) \
          .run()

all my patches are of size 257KB on disk, which I think makes sense if they are RGBA images (256x256x4)/1024=256. However, I also made a few patches at a Windows machine due to another issue, and I have seen these are of different sizes on disk.

I therefore tested, on linux, to patch 5 patches with the the wheel at the top, which again gave patches of size 257KB, and again with the last stable FAST release (4.9.2), which gave patches of varying sizes on disk. To check the 5 patches with the different sizes, I converted one patch created with each wheel to numpy and did np.array_equal(im1, im2), which show they were the same. Thus the images seem to be identical. As I understand, PNG compress images losslessly, so no information should be lost even with the compressed patches. However, is there any reason that the wheel I have been using does not have any compression, while the stable 4.9.2 does, and should this make a difference in any way that I am not thinking of? Or do you think there is another reason to the size difference I have seen?

Thank you in advance :)

[smistad]

I think I might know why. The only change since 4.9.2 in this file is the introduction of the quality parameter. For PNG we use Qt, which in turn uses libpng to save PNGs. PNG uses the zlib algorithm to do lossless compression. Zlib actually have 10 different compression levels. What is the point of that, you might ask when it is all lossless anyway. Well, it is a tradeoff between compression/decompression speed and compression ratio.

There are still a few things that are strange about what you report.

• Why was 4.9.2 not able to compress the image at all? It uses Qts default vales..
• FAST now has a default quality level of 90 of 100, which is quite high. Why did the change increase the compression?

Unfortunately Qt offers no documentation on this.

Sources for more info;

• http://www.libpng.org/pub/png/libpng-1.2.5-manual.html see png_set_compression method
• https://github.com/qt/qtbase/blob/c7a069870ae80f47b32479dc1f8f7161a3238201/src/gui/image/qpnghandler.cpp

[mhoibo]

It was the stable 4.9.2 that does lossless compression (many around 110-190KB), while the new wheel does not seem to compress (patches of size 257KB). I was not aware that there was a quality parameter for PNG as well (I though FAST only had that for JPG, JPEG-XL).

So then if I understand it correctly, the default quality level for PNG is now higher than before, and it looks like it is using 100 in my case, thus the high and constant size?

I will look into the links as well to try to understand it better. Thank you so much for the quick reply!

[smistad]

It is very strange to use a quality parameter for PNG as Qt apparently does. The PNG parameter should instead be called compression as it only controls the amount of compression versus runtime, not the quality of the image. In the latest commit the quality parameter is only used for jpegxl and jpeg images: eb39bcb