The first one is related to all versions of QuPath. I received a .mrxs data with annotated .qpdata and tried to open on QuPath. Whenever I opened .qpdata including annotations, QuPath requested to “set path to missing file”. After the correct path (my own directory of .mrxs) was set, setting file path was requested again when I re-opened the .qpdata. How can I fix the image path of .qpdata file as default?
The second one is related to QuPath 2.0. I updated QuPath 0.1.2 to 0.2.0 yesterday. And my .qpdata was created on QuPath 0.1.2. When I opened the .qpdata on QuPath 0.2.0, the annotations were not calibrated. In other words, annotations located at different regions of its original location (annotated on QuPath 0.1.2). Can I fix it?
Create a project, add the image to the project. Copy the .qpdata file that is named for that image to the data folder of the project you created. Done. Generally you do not want to run qpdata files, the metadata (file locations, not pixel sizes!) is stored in the project.
This gets a little more complicated, and I am not as familiar, but try adding only the single image to a new project as above. Then you can go to the one subfolder in the “data” folder, and copy your qpdata into it. Then delete the data.qpdata, and rename your file data.qpdata. You can also get to that folder via the context menu when right clicking on the image in the Project tab. Again, the files aren’t always back compatible so… YMMV
Files are not intended to be back compatible. That said, you could try to unlock the annotations and move them, I think most of the changes were in the location of the origin, so it should just be a translational (XY shift) change.
Just save the data file once after the path has been set. Otherwise it will not be written to the file.
Or alternatively, add your images to a project. In generally it is a much better idea to use projects rather than individual .qpdata files - and in the future it is possible that some features won’t work outside a project (because they need to access or write other files within the project).
Potentially yes, but if you fix it for v0.2.0 it will be broken for v0.1.2… and the question is whether it’s necessary/a good idea to fix it.
Basically, the file contains a bounding box defining the scanned region. When opening an image with OpenSlide, v0.1.2 didn’t use the bounding box. So for some file formats (including .mrxs and .scn) there could be a large unscanned region included in the image. This could cause problems for some commands like the TMA dearrayer.
The situation got even more complicated where the same file format was supported by both OpenSlide and Bio-Formats, because Bio-Formats would apply the bounding box. So you’d get an image with a different size depending upon which file reader was used to open it.
Consequently, v0.2.0 always now applies the bounding box to crop the region - giving a more sensible image size and better consistency regardless of whether the image is read with OpenSlide or Bio-Formats.
The advice at the end here is to use the same version consistently, in which case it shouldn’t be a problem. Of course it is a problem if you want to open .qpdata files from v0.1.2 with v0.2.0. If it is really critical (i.e. many annotations that were time-consuming to create need to be retained), it would be possible to write a script to update the location of the annotations… but in general my preference would be to avoid mixing data files between versions.