beelabhmc / flower_map Goto Github PK

There are a lot of config options and it might be hard for a user to know how to fill them, despite the comments in the config file. It would be great if we could validate the config file that the user provides.

Snakemake lets us use JSON schemas to do this, but I think we'll need something a lot more robust, especially if JSON schemas don't allow us to conditionally require options based on other options.

Perhaps the best way to proceed would be to create a validation python module that uses argparse or something similar? We could import that module in the Snakefiles.

In resolve_conflicts.py we load the entire orthomosaic into memory just so that we can get its dimensions. This is probably very memory inefficient.
There are a couple of potential solutions:

1. Save the image dimensions in the segments file during the segmentation step, so that resolve_conflicts.py can just load it from there
2. Use a python library that can get the image dimensions without loading the file into memory (unlike PIL)

Traceback (most recent call last):
  File "scripts/transform.py", line 91, in <module>
    [
  File "scripts/transform.py", line 92, in <listcomp>
    list(transform(chunk, camera, seg))
  File "scripts/transform.py", line 46, in transform
    pt = chunk.model.pickPoint(camera.center, camera.unproject(Metashape.Vector(point)))
TypeError: object is not a sequence

see the code

config option for strategy1 vs strategy2

• some sort of boolean?

somehow allow input for already stitched project files?

• or the user could just put them in the output dir

When submitting jobs from the flower-mapping pipeline to SGE via qsub, we encountered an error that indicated that Metashape and other dependencies of the pipeline weren't available. Further investigation revealed that the dependencies of the pipeline had been installed correctly by Snakemake into the different conda environments, but for whatever reason, the modules couldn't be imported at execution time. Weirder still, everything worked when jobs were executed locally instead of submitted via qsub.
The issue proved difficult to replicate; we weren't able to reproduce the problem with smaller, test pipelines. But the errors consistently showed up with the flower-mapping pipeline.
Finally, after a few days of banging our heads, we discovered a similar issue reported in the Snakemake Github's Issues tab. So we reverted from Snakemake v5.32.1 to v5.20.1 and it worked! Based on this information, we speculate that there might be a bug within Snakemake that has yet to be resolved. The issue seems to indicate that the culprit is some code that was changed somewhere around v5.26.0.

Some segments are naturally cut off or split when they are transformed from the orthomosaic coordinates to the original image coordinates.
I currently handle this by simply ignoring coordinates of the segment's contour that don't belong in the image.
However, this won't work if the segment lies in the very corner of the image. Add more coordinates to make the shape more accurate.

@elissahou discovered that stitch.py doesn't work properly when the output path is relative instead of absolute. At the root of the problem is a bug within the Metashape Python API that prevents doc.save() from taking a relative path.

There are three potential ways of solving this:

1. Specify that the output path in config.yml must be absolute
2. Make the Snakefile provide an absolute path when it calls stitch.py and specify that stitch.py requires an absolute path
3. Within stitch.py, convert the output path to an absolute path at some point before using it in doc.save()

Solution 3 might be better, since it attacks the root problem without side-stepping around it. It will also allow people to use relative paths in config.yml

For solutions 2 or 3
One way to convert a relative path to an absolute path within python is to use os.path.abspath. Another way (which uses the new, fancy pathlib module) is to use Path().resolve()

some of the features are calculated on a rectangle containing the segmented region instead of only the segmented region itself

(seems to be related to this)

libtiff error: Maximum TIFF file size exceeded
libtiff error: Maximum TIFF file size exceeded
Traceback (most recent call last):
File "scripts/export_ortho.py", line 25, in
chunk.exportOrthomosaic(args.out)
RuntimeError: TIFFWriteTile: unexpected error: out/6217West/stitch-lowQual/ortho.tiff

it might be possible to parallelize the feature extraction step for each segmented region
the only problem would be that each row of the output must remain in the same order as it was given in the input, so every parallel process would have to hang until its time comes to write to the output