Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can't enable large_image_source_pil to view PNGs #312

Open
MartinKlefas opened this issue Jan 5, 2024 · 20 comments
Open

Can't enable large_image_source_pil to view PNGs #312

MartinKlefas opened this issue Jan 5, 2024 · 20 comments

Comments

@MartinKlefas
Copy link

I've changed the docker-compose.yml file to uncomment ' - /opt/large_image/sources/pil/large_image_source_pil.egg-info' and looked through the girder.cfg and elsewhere to try to enable pil. I'm unfortunatley no closer and when I try to view the images in the histomicsui it still says:
please select a "large image" item

After changing the config I've rebuilt the images, but I still have just the below plugins running:
girder_1 | Loaded plugin "hashsum_download"
girder_1 | Loaded plugin "homepage"
girder_1 | Loaded plugin "jobs"
girder_1 | Loaded plugin "worker"
girder_1 | Loaded plugin "large_image"
girder_1 | Loaded plugin "large_image_annotation"
girder_1 | Loaded plugin "ldap"
girder_1 | Loaded plugin "resource_path_tools"
girder_1 | Loaded plugin "user_quota"
girder_1 | Loaded plugin "virtual_folders"
girder_1 | Loaded plugin "girder_xtk_demo"
girder_1 | Loaded plugin "dicomweb"
girder_1 | Loaded plugin "import_tracker"
girder_1 | Loaded plugin "slicer_cli_web"
girder_1 | Loaded plugin "histomicsui"
@manthey
Copy link
Contributor

manthey commented Jan 8, 2024

You shouldn't have to change the docker-compose file. There is a default maximum size that it will use for PNGs. There are some settings in Admin Console -> Plugins -> gear icon next to Large Image.

@MartinKlefas
Copy link
Author

Thanks, that's working now, maybe the error message could be changed, as I thought I needed to add support for PNG files by including more plugins, rather than just increasing the max size setting.
The problem has changed slightly though, as it looks like girder starts to load all of the images in a collection - I've got 700 images in that one collection, all 300mb PNG files, so within 15-30s it's used all my RAM, and doesn't let go!!

@dgutman
Copy link
Contributor

dgutman commented Jan 11, 2024 via email

@MartinKlefas
Copy link
Author

Well, at the moment the memory usage just keeps going up until the server locks up and dies at 24gb. It starts raising in gb chunks when I go to the image selection screen in the histo plugin and even if I just rush through and pick the first one it keeps increasing.

I'll do a bit of digging this evening - reduce the number of images in the collection etc and see if the usage drops off after going up etc. I'll also check how much ram each image should be using just in case it's more than is available on that mini server.

@manthey
Copy link
Contributor

manthey commented Jan 11, 2024

You can adjust the maximum number of tile sources that can be cached. By default, it makes an estimate for how much memory different sources will use and tries to balance memory use and cache availability, but, it sounds like it is picking wrong. Does adding something like this to the girder.cfg file avoid the problem?

[large_image]
cache_tilesource_memory_portion = 16  # larger numbers use less memory
cache_tilesource_maximum = 32  # smaller numbers use less memory

This example will use the smaller of 32 sources cached or an estimate of the number of sources based on what it thinks would use 1/16th of the memory. What is a typical resolution of your PNG files? Probably if we sent the maximum allowable resolution higher than the default, the estimate is wrong for the PIL source.

@dgutman
Copy link
Contributor

dgutman commented Jan 11, 2024 via email

@MartinKlefas
Copy link
Author

I've done some testing:

  1. I reduced the folder sizes and once the folder has had thumbnails generated, it releases the memory - but only when all the images have thumbnails generated, so if I have one more image than will fit into memory, then things start to break
  2. The second time I go into a folder browser if it's not crashed it doesn't use all that memory again - which is brilliant.
  3. Once I open an image after the folder browser has finished it releases the memory - but if it was still loading the thumbnails it continues that process until it's loaded them all.

Finally: Changing those tilesource settings down dramatically really helped the process of creating the thumbnail images and allowed the folders to finally fully cache. The memory portion had less of an effect than the maximum setting, and I had to set it quite aggressively lower than the memory limit on the machine to get it to stay in bounds. In the end I found 12 (out of 23 available on launching the app) made sure it stayed under about 14 GB of use - where 20 or 16 each meant that it sometimes got uncomfortably close to 99% RAM use.
Setting the max sources made it stick strictly to x number of images scanned at once, which was slower, but more reliable when i set it to 2 - as I knew for certain the RAM use would stay low. Of course this would be less of an issue on a more powerful computer.
Having said all that though, it doesn't seem to always drop the RAM when you pick which image you want to look at after scanning a folder. Here for instance I just

loaded 50 odd images for the first time in the folder thumbnail view, and picked one at random to look at:Screenshot 2024-01-11 222132
oddly this time it's picked bash to assign the memory use to - before it said Girder...
If I shut everything down, load up the same interface, and pick a new image to review, the memory usage is back to normal, as it's not had to make any thumbnails:
image

@dgutman
Copy link
Contributor

dgutman commented Jan 11, 2024 via email

@MartinKlefas
Copy link
Author

Yes, and I think with "proper" formats the creation of the thumbnails is much more memory efficient too - as the files contain thumbnails and don't have to be fully read in?

Anyway it's kind of solved, in that I know how to side step the issue. If you want me to do any other testing let me know!

@dgutman
Copy link
Contributor

dgutman commented Jan 11, 2024 via email

@MartinKlefas
Copy link
Author

Thanks - the uniqueness of this dataset is really coming to light the more I work with it.
Now that I've generated most of the thumbnails the system is working really well - I don't know if it's possible to have a "generate all thumbnails now" button somewhere in the settings for other poor unfortunates with an unusual dataset?

Thanks again

@dgutman
Copy link
Contributor

dgutman commented Jan 12, 2024 via email

@MartinKlefas
Copy link
Author

Sorry i think something was lost in updating the issue by email - it's come through with just image markup and not images

@MartinKlefas
Copy link
Author

Hi - I've tried repeating this process on a new (better) server and unfortunately I can't find the setting I found before that made it work. Has the UI changed a bit since January? All I can find is the "Maximum size of regular images to use without conversion" here:
image
And now Histomics UI doesn't like my PNG files anymore!

@manthey
Copy link
Contributor

manthey commented Mar 20, 2024

There haven't been substantial changes in the last few months. The two settings are still there: if your PNGs are larger than the "Maximum size of regular images to use without conversion", then you'll still have to manually ask to use large PNGs as "large images". Did you have this set larger in your previous version? And, changing this value won't change items already imported, only newly uploaded/imported.

@MartinKlefas
Copy link
Author

Sorry if this is incredibly obvious - how do I manually ask to use large PNGs as "large images"
My understanding is that if I do this, then Large Image will make tiles of my large PNG files etc - is that correct?

If I set that number very high though, it'll just open them as regular images (but not "large images") and save a thumbnail of them in the explorer?

@manthey
Copy link
Contributor

manthey commented Mar 20, 2024

On an item page, there is a button to use a file as a large image:
image
If the file can be read directly (e.g., is internally a tiled format or is below the setting's size threshold), it will be served as is. If not, a tiled tiff file is generated based on the file and stored alongside it, and it is served from there.

The drawback to a high maximum size is that (a) it can use a large amount of memory, since the pngs will be decoded into memory for serving, and (b) if they exceed your browser's GPU's texture buffer memory, they become very slow to view. The benefit is that we don't have to convert them to a tiled tiff and use more memory.

@dgutman
Copy link
Contributor

dgutman commented Mar 20, 2024 via email

@MartinKlefas
Copy link
Author

for img in gc.listItem(###SOMEGIRDERFOLD###): if 'largeImage' not in img: gc.post(f'item/{img["_id"]/tiles?force=false')

This worked brilliantly, thank you - though I did have to do a bit of a shallow dive on the girder client library so I could authenticate first!

@dgutman
Copy link
Contributor

dgutman commented Mar 20, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dgutman @manthey @MartinKlefas