autorate is deprecated

[petoor]

Hi John calling pyvips.Image.thumbnail with auto_rotate as according to: https://libvips.github.io/pyvips/vimage.html#pyvips.Image.thumbnail seems to be deprecated

Message: '{0} argument {1} is deprecated'
Arguments: ('thumbnail', 'auto_rotate')

[jcupitt]

Hi @petoor,

Yes, auto_rotate is deprecated now -- it's always on. It never worked properly anyway, so there's no loss.

Instead, there's a new flag called no_rotate which disable autorotation.

[petoor]

Alright. Is there any way to get Image.new_from_file to understand this as well when fetching height and width? If I use Image.new_from_file to get height and width, which is needed for thumbnail it is fetched like no_rotate So if i run

img = pyvips.Image.new_from_file(input_file)
pyvips.Image.thumbnail(input_file.file.path, img.width/2, height=img.height/2)
pyvips.Image.thumbnail(input_file.file.path, img.width/2, height=img.height/2, no_rotate= True)

I end up with

<pyvips.Image 4608x3456 uchar, 3 bands, srgb>
<pyvips.Image 1296x1728 uchar, 3 bands, srgb>
<pyvips.Image 2304x1728 uchar, 3 bands, srgb>

So the second thumbnail has switched height and width Any good ways to have a consistent setup for this when the exif data is unknown in advance?

(EXIF data is orientation 6 in this example)

[jcupitt]

You can call thumbnail twice. It only actually does the load and shrink when you connect it to something -- just doing

x = pyvips.Image.thumbnail("Gugg_coloured.jpg", 1)

is very quick.

For example:

$ python3
Python 3.8.6 (default, Jan 27 2021, 15:42:20) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyvips
>>> pyvips.Image.thumbnail("Gugg_coloured.jpg", 1, size="up")
<pyvips.Image 1296x972 uchar, 3 bands, srgb>
>>> pyvips.Image.new_from_file("Gugg_coloured.jpg")
<pyvips.Image 972x1296 uchar, 3 bands, srgb>
>>> 

[jcupitt]

... backtracking slightly, it sounds like you want to use thumbnail with a resize ratio rather than a target size in pixels, is that correct? Could you explain the use case?

[petoor]

x = pyvips.Image.thumbnail("Gugg_coloured.jpg", 1, size="up") seems to do the trick. Any reason not to replace Image.new_from_file with this?

I'm using it to create a pyramidal image in a hdf5 file, the images can be 3D or 4D (related to https://github.com/libvips/pyvips/issues/170) which is why i dont use the tiff directly but a hdf5 file.

[jcupitt]

Ah gotcha.

libvips supports OME-style TIFF pyramids now -- lunaphore sponsored development of the feature in the second half of last year. You put the planes into a tall, thin strip, set page-height to indicate the boundaries, then save with the subifd option.

I made a post with an example a few days ago on imagesc:

https://forum.image.sc/t/writing-qupath-bio-formats-compatible-pyramidal-image-with-libvips/51223/6

[jcupitt]

Sorry, I should have updated that issue from last year. I hope I didn't waste too much of your time.

I've added a note now.

[petoor]

No worries. What i have now works, but the ome-tiff style tiff based pyramid is a much better solution. Just to understand correctly, the tiffsave with pyramid=True and the subifd option (ill have to play around with the settings) supports N-D tiff images with an arbitrary number of color channels?

Off topic: It seems that jpeg compression is limited to 65,535×65,535 pixels which would be needed for very large histology images. Do you know if this limit is there as well with jpeg2000? If that is the case i might as well wait for version 8.11 of libvips which seems to support jpeg2000.

[jcupitt]

That's right, it supports 3D volumes. You could probably add more dimensions with a bif of fiffling.

The restriction is that all the planes must have the same dimensions. OME-TIFFs can contain several different volumes with different modalities and sizes, which can be a problem.

Yes, jpeg uses uint16 for dimensions, but in practice it doesn't matter since you should almost certainly use tiling. Large untiled TIFFs have very poor performance in most cases.