| T O P I C R E V I E W |
| vvinyciti |
Posted - Nov 13 2015 : 16:16:49
Hello,
I am using ImageEn library (v.6.0.1, did not install 6.2 yet) in a biomedical application which, among other formats, has to support BigTIFF. Some features of ImageEn age very well suited for viewing big image files, in particular - image navigator. However, it works well only with "small" images. The reason is that the library allocates the bitmap and loads the whole image at once, regardless of its size.
This is regrettable, because with "big" images (in my case - ~20GB, up to 100,000x100,000 pixels) reading the whole file at once takes a lot of time, that is not to mention bitmap allocation issues, which sometimes freeze the application.
Moreover, reading by tiles after setting TIFF_GetTile property does not help for two reasons: 1) even to get one tile the library re-reads the whole file, so the update of the screen for visible tiles takes very long time; 2) as far as I know, the library does not provide any method to get "X*Y" area of tiles.
So, I have two questions:
Does anyone have experience with reading BigTIFF images (>~20GB) using ImageEn?
Is it possible to get some information regarding the future plans to improve tiles reading functionality? |
| 9 L A T E S T R E P L I E S (Newest First) |
| xequte |
Posted - Dec 06 2020 : 16:59:40
Hi
Can you upload a test file for us to evaluate here.
Nigel
Xequte Software
www.imageen.com
|
| davenovo |
Posted - Dec 06 2020 : 14:15:43
Hello,
I see that this post is a few years old. We have a similar requirement, to efficiently load tiles from BigTiff image as quickly and with as little memory overhead as possible.
As with the OP, we need to load tiles from images that can easily be 20Gb. The images also may be compressed.
Have any improvements been made in this regard? |
| xequte |
Posted - Nov 19 2015 : 15:27:29
Hi
I agree that ImageEn needs improvement in this area. If this is an important area for other users too, then I would like to hear from them.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
| vvinyciti |
Posted - Nov 18 2015 : 23:19:04
Unfortunately, I have to take back what I said before. Uploading of my average file (20.5 GB originally, 7.5 GB after compression) will take ~22 hours. Additionally, to upload such a file I will have to split it in ~12 sections and start the upload manually one by one. I have no resources to do this now. That is not to mention that I have to find some file sharing service which allows to store these files. The service that I use now gives only 5GB space. Sorry. But thank you for asking about it. :-) |
| vvinyciti |
Posted - Nov 18 2015 : 20:40:34
Hi Nigel,
Thank you again for your reply. I can upload images, but it is not a trivial thing. With current speed of my Internet connection it will take many hours. I will try to run the upload at night. If it will get through - I will post the link here. And please, understand me correctly: I do not need a refund. Many features of the library are very helpful and work very well, which sets the expectation bar rather high. Unfortunately, BigTIFF support is not quite up to this standard :-( |
| xequte |
Posted - Nov 18 2015 : 16:15:19
Also, I would appreciate if you could upload some of your TIFF files for my analysis.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
| xequte |
Posted - Nov 18 2015 : 16:14:59
Hi
ImageEn supports reading of BigTIFF files (i.e. TIFF files with 64bit offsets) so of course it is not incorrect to state that fact. However our method of handling Tile support is not optimal, so for huge files it is inefficient.
We expect to improve in this area, but ImageEn is a customer driven product, i.e. we add the features we believe will benefit our customers most (e.g. by making note of features requests) so I cannot say when that will be.
If you are dissatisfied with your purchase, or feel we have mislead you, please email us for a refund.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
| vvinyciti |
Posted - Nov 17 2015 : 21:39:35
Thank you for your reply. However, it is disappointing.
First, I did not say that it "loads the whole image", I said it re-reads the whole file, which does not implies allocation of the whole image.
But it is a minor issue. More importantly, if I understand your answer correctly, you do not even consider that BigTIFF support is implemented incorrectly. This is very unfortunate.
The way how reading of one tile is implemented does not make it useful. It is necessary to restructure practically the whole library just to do the simple reading of tiles from the TIFF file stream in a loop without creating and re-creating the stream object, the context object, TIOParamVals etc. over and over again. I should be able to create a stream object once and read tiles using the stream and array of offset pointers.
The bottom line is: how can you claim that BigTIFF format is supported, if reading by tiles practically does not work? Huge image or not so huge image, but BigTIFF format support requires efficient and quick reading of tiles at random, especially if the navigator is used. So, it does not matter how many users are interested. If you advertise that ImageEn library has BigTIFF support you should implement it correctly, otherwise it is just a false claim. |
| xequte |
Posted - Nov 17 2015 : 18:21:33
Hi
Actually TIFF_GetTile does not load the whole image, however it could be further optimized to avoid loading the file header every time.
I'd also like to hear from other users interested in support for huge tiffs.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
|
|
Search
