search

flathub / org.libvips.vipsdisp

https://flathub.org/apps/details/org.libvips.vipsdisp
1 stars 2 forks source link

Unable to access files in /mnt and /srv #2

Closed ximion closed 2 years ago

ximion commented 2 years ago

Hi! We have a lot of our data on network drives mounted under /mnt. It would be cool if those were accessible from the Flatpak as well, so would it be possible to relax the sandbox permissions a bit to allow /mnt and also /srv (where data also sometimes is stored)? Cheers, Matthias

jcupitt commented 2 years ago

Hi @ximion, sounds reasonable, could you suggest the changes needed? I'm not very good with flatpak.

ximion commented 2 years ago

I created a PR for it, giving file access is pretty straightforward. I do wonder whether there should be a shorthand for "allow all data access that's not just in $HOME but includes /mnt" for Flatpak... But for now, this should work :-)

jcupitt commented 2 years ago

Thanks!

(I've just discovered that I stupidly built libvips and vipsdisp in debug mode sigh. I'll do a new flatpak binary and include your patch too)

ximion commented 2 years ago

I've just discovered that I stupidly built libvips and vipsdisp in debug mode sigh.

Ah! I just discovered the tool and was testing it on our systems and was quite surprised how outrageously slow it was (given that libvips is rather fast!), but that definitely explains why! Thank you for your work! :-)

jcupitt commented 2 years ago

It should be pretty quick even in debug mode. Is there a particular image type it struggles with?

The info bar (the thing that shows x, y, value) is updated in the GUI thread (unfortunately), so that can cause nasty stuttering for some images. You could try with that off.

ximion commented 2 years ago

It should be pretty quick even in debug mode. Is there a particular image type it struggles with?

I was feeding it a 10GiB OME-TIFF (Z-stack with 2 channels and 200 slices), the individual slices were also quite large (I think about 3200x3200px) - any update to the displayed image too multiple seconds. Could also have been a remove connection thing, but ImageJ is processing this type of image just fine. I need to play around with this some more :-)

jcupitt commented 2 years ago

Ah OME-TIFF is better, but still a bit wonky -- it only displays some OME-TIFFF images correctly. It's probably in pages-as-bands mode and trying to show it as a 200-channel colour image (!!). If you use multipage mode it should be fast.

It needs some more logic to detect a sensible number of pages to join up for a colour image, and something to stop it joining pages which differ in size.

I improved the binary a bit, it's building now, there should be a new version on flathub in a few hours.

jcupitt commented 2 years ago

(if you have a sample horrible OME-TIFF image you could share, it'd be great to have a monster for testing)

ximion commented 2 years ago

if you have a sample horrible OME-TIFF image you could share, it'd be great to have a monster for testing

I can see if I find one that is not scientifically valuable and that I can share :-) (I recently recorded tissue that was very degraded, maybe that's a candidate)