Ome.tif write time

[ajr82]

Firstly, this is excellent and than you for your efforts! This is more of a query and not a bug.

I have one HandE and three H-DAB .svs files and valis has registered them very well.
I am writing them as ome.tiff files and it seems to take a very long time to write each file. Is this expected or am I doing something incorrect?
This is the code I am using:

from valis import registration
slide_src_dir = "D:\Documents\Img\"
results_dst_dir = "./slide_reg"
registered_slide_dst_dir = "./slide_reg/registered_slides"
reference_slide = "D:\Documents\Img\A1_HandE.svs"
registrar = registration.Valis(slide_src_dir, results_dst_dir, reference_img_f=reference_slide, align_to_reference=True)
rigid_registrar, non_rigid_registrar, error_df = registrar.register()
registrar.warp_and_save_slides(registered_slide_dst_dir, crop="all", compression="jpeg")
registration.kill_jvm()

Thank you!

[cdgatenbee]

Hi @ajr82,

Glad to hear valis is registering your slides well :) Regarding your question, your code looks good, but could you please clarify how large the registered images are, and how long it is taking to save them? Also, do you know if you have libjpeg-turbo installed (possibly similar issue here, which is relevant because valis uses pyvips/libvips to save the images). One thing I can see is that you're using crop="all", which can result in fairly large images because the output has to be big enough to include all of every image, as nothing gets cropped. Often this results in very large images with a great deal of empty space. Cropping to the areas that overlap with your reference image (the default when align_to_reference=True, or crop=reference), or only the area where all tissues overlap (crop="overlap") will result in smaller images that should save faster. Also, since you're setting align_to_reference=True, the images will look the same as those in the thumbnail folders if you set crop=reference. Anyhow, if either of those cropping options are acceptable they should result in more manageable images.

Best,
-Chandler

[ajr82]

Hi Chandler @cdgatenbee,
Thanks for getting back. My images were 119,818 x 117,011 px and about 1-2 GB svs files. So there are definitely large files. It took about 15 to 24 minutes to save each file. I did not have libjpeg-turbo installed.
I will install it and also try the crop and align_to_reference settings that you have mentioned.

Thanks,
Ajay

[chengdonglin]

libjpeg-turbo
@ajr82
do you have quick the speed by install libjpeg-turbo?

[smith6jt-cop]

Hello, I am also getting great registration results, but am wondering if I can change anything to speed up the results. I am registering 15 4-channel 9000x9000 pixel images and it is taking about an hour with a 64GB Windows machine using WSL2 given 50GB of memory 8-core i7-7700K @4.20GHz. Here is my code:

from tifffile import imread
import valis

from valis import registration, valtils
import numpy as np

import sys
import os
import shutil
from glob import glob

pos = "8"
slide_src_dir = "/home/smith6jt/CX_21-014_SP-CC2-A_LED36_Stitched_merged"
results_dst_dir = "/home/smith6jt/reg_results/"+pos
registered_slide_dst_dir = "/home/smith6jt/reg_results/slides"
merged_slide_dst_f = "/home/smith6jt/reg_results/merged/CX_21-014_SP-CC2-A_LED36_Z"+pos+".ome.tiff" # Where to save merged slide
rigid = True
save = True
verbose = True

#reference_img_fname = "cyc007_Z=0C=0.tif"
img_list = [os.path.join(slide_src_dir, x) for x in os.listdir(slide_src_dir) if x.endswith("Z="+pos+".tif")]

if verbose:
print('==== Rigid Registration Error')

# Split and print error data into multiple columns
num = 4
delta = len(error_df.columns) // num
for _num in range(num-1):
    print(error_df[error_df.columns[_num*delta:(_num+1)*delta]])

if save:
print('==== Saving ome.tiff file; Rigid:', rigid)

channel_name_dict = {"cyc001_Z="+pos+".tif" : ["DAPI", "Blank1a", "Blank1b", "Blank1c"],
"cyc002_Z="+pos+".tif" : ["DAPI", "CD31", "CD8", "Empty2"],
"cyc003_Z="+pos+".tif" : ["DAPI", "CD20", "Ki67", "CD3e"],
"cyc004_Z="+pos+".tif" : ["DAPI", "SMActin", "Podoplanin", "CD68"],
"cyc005_Z="+pos+".tif" : ["DAPI", "CD69", "CD21", "CD4"],
"cyc006_Z="+pos+".tif" : ["DAPI", "Lyve1", "CD45RO", "CD11c"],
"cyc007_Z="+pos+".tif" : ["DAPI", "CD35", "ECAD", "CD107a"],
"cyc008_Z="+pos+".tif" : ["DAPI", "CD34", "CD44", "HLADR"],
"cyc009_Z="+pos+".tif" : ["DAPI", "Igm", "FoxP3", "CD163"],
"cyc010_Z="+pos+".tif" : ["DAPI", "CD271", "CollagenIV", "Vimentin"],
"cyc011_Z="+pos+".tif" : ["DAPI", "CXCR5", "CD15", "CD45"],
"cyc012_Z="+pos+".tif" : ["DAPI", "Empty12", "CD5", "CD1c"],
"cyc013_Z="+pos+".tif" : ["DAPI", "Empty13", "Prox1", "Empty13b"],
"cyc014_Z="+pos+".tif" : ["DAPI", "Empty14", "CD45RA", "Empty14b"],
"cyc015_Z="+pos+".tif" : ["DAPI", "Blank15a", "Blank15b", "Blank15c"]}

merged_img, channel_names, ome_xml =
registrar.warp_and_merge_slides(
merged_slide_dst_f,
channel_name_dict=channel_name_dict,
drop_duplicates=True,
crop="overlap",
interp_method="bicubic",
tile_wh=1024,
compression="lzw")

registration.kill_jvm() # Kill the JVM

Thanks!

[cdgatenbee]

Hi @smith6jt-cop,
Glad to hear you're getting some good registration results! Unfortunately, I'm not sure there is much I can do to speed up the write times, which I know can be pretty long for IF images. I did a quick test comparing write times using .tiff and ome.tiff using libvips (which is very fast), and while the former was substantially faster, the images didn't open correctly in QuPath. I'll do more experimenting and digging to see if there is something else I can do, though.

Best,
-Chandler

[smith6jt-cop]

Thanks for checking! Good to know I was not doing something wrong to cause an unnecessarily long write time. My only other issue now is that even though I set imgs_ordered=True for registration.Valis argument, I get random order of merged channels which is a problem for the final 3D hyperstack. Perhaps this is related to the long runtime or maybe it is another issue? Do you think I can somehow access each ome_xml for every zslice and force an order to the channels during merge to avoid having to redo the registration?

Also, perhaps this is a naive question, but is it possible to avoid generating pyramid images? After VALIS registration when I open in ImageJ, I am confronted with 5 series of images for any processing when I think it would be better to just have the highest resolution, then check the box in QuPath to "Auto-generate Pyramids."

[cdgatenbee]

Hi @smith6jt-cop,
Thanks for brining this to my attention. I think the issue about the channels not being in the correct order in the 3d hyperstack is probably a bug, but one that should be relatively straight forward to fix. But just to confirm that I understand correctly, the thumbnails in the results folder are in the correct order, but not in the merged image? I'll add that fix and the option to save non-pyramid images to list things to include in the next release (1.0.3).

Best,
-Chandler

[smith6jt-cop]

Thanks again for your help. Yes the thumbnails are in the correct order but when merging the cycle/channel order is entirely random from what I can tell. Attaching a file with a few of the merged channel order results in case it helps.

Would channel_name_dict=dict(sorted(channel_name_dict.items())) for the above dictionary work for now?

VALISchannels.txt

[smith6jt-cop]

Should probably move this to a new issue. I found that registrar.original_img_list was out of order for warp_and_merge_slides even with imgs_ordered=True at registration. I was able to get the correct order with:

`valis.registration.init_jvm(mem_gb=50)
registrar = valis.registration.load_registrar(src_reg)
im_name = sorted(registrar.original_img_list)
registrar.original_img_list = sorted(registrar.original_img_list)

ch_name = [["DAPI", "Blank1a", "Blank1b", "Blank1c"], ["DAPI", "CD31", "CD8", "Empty2"], ["DAPI", "CD20", "Ki67", "CD3e"], ["DAPI", "SMActin", "Podoplanin", "CD68"], ["DAPI", "CD69", "CD21", "CD4"], ["DAPI", "Lyve1", "CD45RO", "CD11c"], ["DAPI", "CD35", "ECAD", "CD107a"], ["DAPI", "CD34", "CD44", "HLADR"], ["DAPI", "Igm", "FoxP3", "CD163"], ["DAPI", "CD271", "CollagenIV", "Vimentin"], ["DAPI", "CXCR5", "CD15", "CD45"], ["DAPI", "Empty12", "CD5", "CD1c"], ["DAPI", "Empty13", "Prox1", "Empty13b"], ["DAPI", "Empty14", "CD45RA", "Empty14b"], ["DAPI", "Blank15a", "Blank15b", "Blank15c"]]

channel_name_dict = {im_name[n]:ch_name[n] for n in range(len(im_name))}

merged_img, channel_names, ome_xml =
registrar.warp_and_merge_slides(
merged_slide_dst_f,
channel_name_dict=channel_name_dict,
drop_duplicates=True,
crop="overlap",
interp_method="bicubic",
tile_wh=1024,
compression="lzw")`

[cdgatenbee]

Hi @smith6jt-cop,
Glad you got this working. Was the fix setting registrar.original_img_list = sorted(registrar.original_img_list)?

Best,
-Chandler

[smith6jt-cop]

Actually I just put that line in there to be extra thorough. I just ran it without that line and the sorting is still correct so I'm not sure what the fix is. It could be passing the sorted list to the function in the dictionary or not using an explicit dictionary.

We are in a time crunch for a manuscript resubmission and I was wondering what your timeframe is for a version writing non-pyramid images in warp_and_merge_slides? Perhaps you could point me in the right direction for a temporary fix? I tried editing line 2963 of slide_io.py to pyramid=False (also, should the img.tiffsave function be indented at line 2961?), but our large 10022X9541X46channel images are still being written as 5 level pyramids. I am using VS Code to edit the docker files though so maybe I am not doing something correctly there.

Many thanks!

[cdgatenbee]

Hi @smith6jt-cop,
I don't think it will be too long before i can push the next update, but there are still a few outstanding issues I'd like to address, so I'm a bit hesitant to say exactly when that would be. However, I was working on adding the non-pyramid option today, and I found that in addition to setting pyramid=False, it is also necessary to set subifd=False in img.tiffsave, as I was also still getting pyramid files when pyramid=False and subifd=True. Would that work for a temporary fix?

Best,
-Chandler

[smith6jt-cop]

Yes that did it, thank you! I'm a little surprised the write time is nearly the same, but the file is now ~6GB instead of ~9GB. Downstream processing will be much easier.