Changing µm to pixel for the centroid value

Hello everybody,
I was wondering if anyone knows if I can change µm to pixels when I export the measurements for the centroids.
Or if I can export the image height and width when saving detection results, so I can manually calculate the corresponding pixel coordnate.

Any help is appreciated!

Do you only want to export centroids? If so that should be easier, and the values would be in pixels by default.

For example, assuming you are working within a project then the following script should write the x and y coordinates of the ROI centroids for all ‘detections’ to a tab-delimited file

// Create a file & initialize with the header
def path = buildFilePath(PROJECT_BASE_DIR, 'centroids.tsv')
def file = new File(path)
file.text = 'x\ty'

// Write centroids with tab separator
for (p in getDetectionObjects())
    file << System.lineSeparator() << p.getROI().getCentroidX() << "\t" << p.getROI().getCentroidY()

print 'Done!'

Note that this may use more decimal places that you need, and for cells it will use the centroid of the full cell boundary (not the nucleus).

I am running “Cell detection” on a whole image slide (ndpi file). Afterwards i would like to export the detection results, but the centroids are given in µm instead of pixels. Is there a way to change that?
Alternatively I would like to export the height and width, because based on these values i can calculate the exact pixel width. I need more decimal places than the usual 0.2207

I can’t think of any straightforward* way to convince QuPath to use µm in the measurement table. But you can access the pixel size values with greater precision using the following:

server = getCurrentImageData().getServer()

print server.getPixelWidthMicrons()
print server.getPixelHeightMicrons()

*-I say ‘straightforward’, because in v0.1.2 you can use this terrible hack to trick QuPath into thinking the pixel size is 1:

server = getCurrentImageData().getServer()

server.metadata.pixelWidthMicrons = 1
server.metadata.pixelHeightMicrons = 1

Certainly not to be recommended - it takes advantage of Groovy’s forgiving nature to manipulate private fields, loses the ‘true’ calibration information, and would need amended for later versions - but… well, it’s possible.

Thank you very much for the help!