I did a conversion with Irfanview using the Windows Command Line (advancedbatch) from TIFF Packbit to TIFF LZW. When I open the file in ESA SNAP it loads extremely slow. I have the same Picture which was converted in the same way with Irfanview last year which works just fine. In the Metadata the only difference is the RowsPerStrip. Do you have an idea why it loads extremely slow?
One more question. Sorry, should have asked this before.
What shows SNAP when you open the information window (Analysis / Information). Especially I’m interested in the preferred tile width and height. Is this is not in line with the striping of your data, this could be a reason for the slowness.
ich habe gesehen, wir können auch auf Deutsch wechseln…! Hier sind nochmal Screenshots von dem Info Fenster. Beide Dateien unterscheiden sich hier in keinem Punkt. Können Sie das ‘Is this is not in line with the striping of your data, this could be a reason for the slowness’ näher beschreiben?
ja wir könnten auf deutsch weiter reden, aber dann würden uns viele anedere nicht verstehen.
So, it is better to stick to English, then everyone can benefit from the discussion.
Can you send me the two files? Maybe as links in a PM? If not, I can provide a location where you can upload them.
The differences in the striping of the Tiff file and the tile size in SNAP can be a reason for the slowness because of the way the data is read. If a 320x320 tile shall be read by SNAP all 1024 rows must be unpacked and for the next tile again, and again… There is no caching implemented.
But actually these values should be inline and then only the data for one tile is unpacked. So this might be a bug in the reader. Your data will be helpful to reproduce the behaviour and fix the issue.
I had a look at your files and it behaves as you say. But I couldn’t figure out why the second one is slow.
We check if the tiling is good if it is not we compute our own tiling size and use it. This works quite well if the data is not compressed, but it is probably contradictive when compression is used. We consider a tiling as bad if the tiles span the full width or height of the image or just one line or row. In the terms of memory management and read performance, this is bad. For images this usually doesn’t matter, that’s probably why IrfanView does this, but for EO data this can be a difference.
However, even if I use the predefined tiling by the files it is only slightly better.
I tried to change how the data is read and this gave much better results. The slow image was displayed after 2 seconds instead of 20-30 seconds. Unfortunately, the new implementation results in other errors. So, this needs more testing and validation but at the moment I can’t spend more time on this. I’ve created a ticket in our issue tracker so that we can follow the problem later.
From the messages.log a few NullPointerExceptions were thrown.
Tracing the code to it.geosolutions.imageioimpl.plugins.tiff.TIFFLZWDecompressor, they were caused by the following 3 situations:
NullPointerException at line 278 below:
because stringTable[oldCode] passed from line 215 of the caller method is null.
NullPointerException at line 219 below because stringTable[oldCode] from line 218 is null:
NullPointerException at line 265 below:
because stringTable[code] passed from line 214 of the caller method is null:
It appears to me that TIFFLZWDecompressor.decode() may possibly be run concurrently by multiple TIFFImageReader.decodeTile(int ti, int tj, int band) calls causing stringTable in TIFFLZWDecompressor class to have null values.