what resolution do we need?

[lizzieinvancouver]

I have been asking colleagues ... Here's a reply from Alana (who @christophe-rd has chatted with for other reasons):

Your AI ref with all the training images (OMG!) used CNN, which can be replaced with FCN with better results and vastly fewer training images. Ballpark 50, but I would test at 30. I am doing loads of this FCN stuff to segment my CT scans, so I have Python code and the GPUs, if you’re interested. My buddy Devin Rippner runs his on Google Collab, he’s got a methods paper and Git repository for that that’s easy to find. Once you have a model, most computers can implement it.

Anyhow, the answer is going to depend on the species and what you want beyond dendro data. I think the second lowest res would work for visual ID. For sure with the 2 highest res scans you could make an ImageJ macro that counted and measured the vessels per ring. That seems like a potential breakthrough, to link a trait we can really calculate some stuff with to annual growth. Oooooo

[lizzieinvancouver]

@afong3 @chloecurry Any chance we could offer different versions? One that is low resolution for rings and works well and one that is 0.9 resolution and in beta mode for vessels etc.?

[afong3]

@lizzieinvancouver I mentioned this briefly in the presentation last week but I thought I'll add this here as well for completeness. A cascading level of resolutions will be made for each cookie - 5, 10, 20, 30, ..., 100% of total resolution. If the stitched image at a specific resolution is less than 2.5 GB (the maximum size for a TIFF file), a tiff file will be created. If the stitch is greater than this (which will already prevent itself from opening in most image viewers), a custom viewer will need to be used. The nice part about .dat files is that they can be opened using numpy memory maps (np.memmaps) which don't load any of the data into RAM.

[lizzieinvancouver]

@afong3 Sounds great! I assume people can deselect or discard higher resolution images easily during the process ... I am thinking if I don't want 10 GB images (dat files) created, can I deselect the higher resolutions to try to avoid this?

[afong3]

@lizzieinvancouver The current process blindly creates the resolution cascade and it would be up to the user to not move the folders from the system to their computer. I'll think about where to add a entry box in the GUI to allow for a hard file size limit - stopping any higher resolution stitching once the limit is reached. I could definitely see how it would be futile to be wasting processing time on creating massive mosaics without use cases.

[lizzieinvancouver]

I'll think about where to add a entry box in the GUI to allow for a hard file size limit - stopping any higher resolution stitching once the limit is reached. I could definitely see how it would be futile to be wasting processing time on creating massive mosaics without use cases.

@afong3 Sounds good. If not possible, we'll just need to lay out some clear rules for people as I could see some folks (like me) blindly setting up something insane with a giant cookie creating a big file I will never use and wondering why it is taking so long.

[afong3]

@lizzieinvancouver Maybe it would be a little more intuitive to add the estimated file size of the largest file to the popup screen which already includes progress bar while the cookie is being captured?

[lizzieinvancouver]

@afong3 That sounds good. And if the size is way larger than they want, we suggest they do what?

[afong3]

@lizzieinvancouver If the size is far too big, it would probably be best to just cancel the process and restart at a different zoom level to make the field of view larger and decrease the overall resolution.

[lizzieinvancouver]

@afong3 Got it. That seems reasonable. You consider bold-ing the biggest size and adding a note that says as much (or an asterisk and a footnote) or such.