Opening .scn with QuPath-m0.2.3 CLI on Linux

Usage & Issues
#1

I am trying to run scripts on some .scn slides by QuPath-m0.2.3 on Linux.

./QuPath-m0.2.3 script tile_exporter.groovy -i myslide.scn

The exported tiles are generated from the macro image, instead of slide image data.
I have tested a .svs and it works fine.
Wehn I drag and drop the .scn into QuPath GUI on windows, a prompt pops up and ask me which image I would like to open. Is there an equivalent in scripting?

How do I export the slide image data instead of the macro image of .scn?

Official tile exporter script from the docs:
tile_exporter.groovy

/**
 * Script to export image tiles (can be customized in various ways).
 */

// Get the current image (supports 'Run for project')
def imageData = getCurrentImageData()

// Define output path (here, relative to project)
def name = GeneralTools.getNameWithoutExtension(imageData.getServer().getMetadata().getName())
def pathOutput = buildFilePath(PROJECT_BASE_DIR, 'tiles', name)
mkdirs(pathOutput)

// Define output resolution in calibrated units (e.g. µm if available)
double requestedPixelSize = 5.0

// Convert output resolution to a downsample factor
double pixelSize = imageData.getServer().getPixelCalibration().getAveragedPixelSize()
double downsample = requestedPixelSize / pixelSize

// Create an exporter that requests corresponding tiles from the original & labelled image servers
new TileExporter(imageData)
    .downsample(downsample)   // Define export resolution
    .imageExtension('.tif')   // Define file extension for original pixels (often .tif, .jpg, '.png' or '.ome.tif')
    .tileSize(512)            // Define size of each tile, in pixels
    .annotatedTilesOnly(false) // If true, only export tiles if there is a (classified) annotation present
    .overlap(64)              // Define overlap, in pixel units at the export resolution
    .writeTiles(pathOutput)   // Write tiles to the specified directory

print 'Done!'
#2

The problem is likely that the .scn image is being read by Bio-Formats, which provides access to multiple series (images) from a single file, and QuPath is taken the first of these by default. Often the first series is the whole slide image so all works well… but here it seems to be the macro image instead.

The easiest workaround is to add your images to a project first. Then you can control which series is included in the project. This involves using the UI initially to create the project, but afterwards you can specify the project and image from the command line.

I don’t remember if there is a way to specify any other series from the command line when you don’t have a project. I don’t think there is currently, but @melvingelbard might have an idea.

#3

I would suggest the same as @petebankhead. It seems to be the cleanest way to achieve what you want.

In case you have a lot of images to process, you could add them all to one project (using the GUI). Then run your script for the whole project.
Either you filter out manually the entries in your project with the GUI before running your script, or your script would need some logic to filter out irrelevant images.

1 Like
#4

Hey Pete and Melvin,

Thank you for the suggestion.
Yea I agree using.qpproj should be easier on GUI and is the recommended way.
However, if I create the qpproj on windows command line, the slides uri are created with respect to my windows os. When I do that on my VM instances on cloud, the slide uris are different. I could not update the uri with QuPath GUI on Linux. That’s why I was thinking to apply the script on a per slide basis.

I actually have some python scripts to update the dictionary in the .qpproj when I was working with m-0.1.2. I suppose this could be a hacky fix.
Nevertheless, I want to keep it as simple as possible for dockerize later.

Either you filter out manually the entries in your project with the GUI before running your script, or your script would need some logic to filter out irrelevant images.
Which documentation do you recommend reading?

#5

The official docs are available here. But for instance you could get some ideas here, which shows you how to access the current ImageData.

Also, you’ll find on this forum a lot of posts with little samples of code doing pretty much anything. You could use something as simple as getProjectEntry().getImageName() to check for the name of the current entry (and check for '[macro]' keys, or an exact match for the name), or anything else really.