Object detection in raw imagery

[bw4sz]

Summary

Can I use EasyIDP to find the location in the orthomosaic from a point in the raw images? This is the opposite workflow of the current project. This workflow would be widely applicable to machine learning object detection pipelines and be of interest to a large audience. I am happy to contribute to a PR if this fits the scope of this project. It is very possible that this functionality already lives inside the project, but is not seen as a primary user workflow (see below).

Use Case

I am a machine learning researcher at the University of Florida (https://scholar.google.com/citations?user=7POnELAAAAAJ&hl=en) I develop python tools and datasets for object detection in airborne imagery https://deepforest.readthedocs.io/.

I am often asked whether it is better to predict in the raw images versus the orthomosaics created from UAV imagery. Reading the paper (https://www.mdpi.com/2072-4292/13/13/2622), we are in agreement of the importance of using the highest quality imagery.

Third, limited by the complex field conditions, the concatenated DOM often has image
quality diminution compared to raw images [16]. A technique called reverse calculation,
which links the same place from DOM back to relative raw UAV images, has attracted
extensive interest [8,16–18], as it not only improves the ground cover estimation accuracy [8]
but also enables small-organ (e.g., sorghum head) detection tasks from UAV images [17,18].

For example, we have a nice 6 species bird detection model we have developed for our UAV orthomosaics.

but we often see that these georeferenced orthomosaics can have significant artifacts, likely because the trees/birds move among images, leading very blurred pixels. However, in wildlife ecology, we often want to use a georefenced image for time-series, or counting, or other use cases. Therefore if we make predictions in the raw images, we still need to find their location in the orthomosaic. FYI, the orthos were made before they get to me, so i'm still learning the agisoft terminology, but I have a solid remote sensing background.

Current State

The package currently provides functionality to identify the location in the raw images from selecting an ROI in the orthomosaic. Under this setup, a current object detection workflow would be

1. Capture raw images
2. Create a orthomosaic (agisoft)
3. Use an object detection model to find objects of interest
4. Use EasyIDP to find the location of detected objects in raw images
5. Re-run model (classification only?) on the corresponding raw image locations
6. Ensemble the predictions from the raw images and associate them with the original geospatial ROI

if we had a raw to orthomosaic mapper the workflow would be

1. Capture raw images
2. Predict object detection model
3. Create a orthomosaic (agisoft)
4. Use EasyIDP to find the location of detected objects in orthomosaic
5. Non-max suppression of overlapping boxes.

Existing solutions

I see a class that I think forms the basis of this work:

EasyIDP/easyidp/reconstruct.py

Line 401 in 0d074ca

class ChunkTransform:

EasyIDP/easyidp/metashape.py

Line 93 in 0d074ca

def _local2world(self, points_np):

but they are not documented and look like _internal functions.

What I've tried so far.

Here is the package of data I'm working from.

https://www.dropbox.com/sh/1gc5k0kvryhnxnm/AAANNgZHl05SrIfHnt1mz8Kca?dl=0

I made a sample ROI

A couple errors that I ran into

import easyidp as idp
proj = idp.ProjectPool()
proj.add_metashape(["/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/Hidden_Little_03_24_2022.psx"])
roi = idp.ROI("/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/example_bird.shp") 
chunk1 = proj[0]
img_dict = roi.back2raw(chunk1)
img_dict = roi.back2raw(chunk1, save_folder="/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp")

first, the proj object is empty

proj
{}

When trying read the ortho, I get

ortho = idp.GeoTiff("/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/Hidden_Little_03_24_2022.tiff")
Traceback (most recent call last):
  Python Shell, prompt 24, line 1
    # Used internally for debug sandbox under external interpreter
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/geotiff.py", line 21, in __init__
    self.read_geotiff(tif_path)
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/geotiff.py", line 34, in read_geotiff
    self.header = get_header(str(tif_path))
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/geotiff.py", line 562, in get_header
    raise KeyError("Can not find key 'GTCitationGeoKey' or 'PCSCitationGeoKey' in Geotiff tages")
builtins.KeyError: "Can not find key 'GTCitationGeoKey' or 'PCSCitationGeoKey' in Geotiff tages"

but it reads fine in rasterio

rio.open("/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/Hidden_Little_03_24_2022.tiff").crs
CRS.from_epsg(4326)

This could easily be due to my lack of familiarity with agisoft, I doubt it implies a larger issue. Once we get these sorted out we can discuss the larger questions above.

All thoughts welcome, thanks for your work on this important and overlooked area of development.

[HowcanoeWang]

Thanks a lot that you are willing to use our tool.

Just a quick conclusion, you can not project from raw to DOM directly due to the dimension loss

The theory:

The package needs DOM + DSM to get a 3D coordinate in the real world, and then according to the "direction" of each photo calculated by SfM, it produces a 3D->2D projection on the raw image. In this procedure, the information is lost from 3D to 2D. You can not fix that information loss if revert from a 2D raw image coordinate to the 3D world coordinate directly (You will get several rays for the ROI vertex rather than specific 3D coordinates)

The ChunkTransform class and _local2world function are inner used by back2raw() to deal with the transformations of 4 coordinates in the Metashape. They should not be what you want.

But you can achieve this in an alternative way (we are drafting this application for a journal now). You can first split the DOM into several grids, and project each grid to the corresponding region on the raw image (probably the closest one is enough). Then you can "intersect" them with your raw image detection results (or simply do detection on the projected region area). And then for each grid, calculate its own transformation matrix from DOM coordinate to raw image coordinate. Lastly for this grid, you can move the detection results on the raw image back to the DOM by the inverse transformation matrix. (Apologies we haven't had time to integrate this approach to an easy-to-use API in the EasyIDP before publishing the paper)

Currently, limited by the heavy workload from other projects in the lab, the EasyIDP is not completely coded (too many complaints from co-workers for v1.0, we are completely reconstructing the API in v2.0 for easier use, coding almost 70% with docs only around 20%). For example, this batch processing code has not been implemented in the current v2.0.0.dev3:

proj = idp.ProjectPool()
proj.add_metashape(["/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/Hidden_Little_03_24_2022.psx"])

But alternatively, the base object for each metashape and pix4d project have been finished, you can try it equally by:

ms = idp.Metashape("xxxx.psx", chunk_id=0)   # please check the folder in xxxx.files.
ms.back2raw(roi)   # save_folder parameters in the readme also not implemented yet.

Then for the metashape project files in your dropbox, the xxxx.files folder is more important than the xxxx.psx file, all the information the EasyIDP required are in that folder (easpecially xxxx.files/0(chunk_id)/chunks.zip ), very appreciative if you are willing to share that folder in the dropbox (probably you don't have to upload the large file contents within the subfolders of xxxx.files/0/0/*, but please keep the frame.zip file in that folder, others are intermediate results that EasyIDP won't use, you can delete them in the dropbox).

And for the errored GeoTIFF file, very appreciate if you can share the problem GeoTIFF via Dropbox, it will be a good source for debugging, and I will try my best to find a solution for it. I guess it may have some important offset value missing or renamed in the 'XxxxCitationGeoKey', Also, just in case it is the problem caused by DOM exporting, here is the parameter settings that we used in the Metashape, provided here for your reference.

For our agricultural proposes, using EPSG:4326 (lon, lat) may not a proper for size estimation. We prefer the UTM geo-coordinate instead because the units of x and y are in meters. (For Florida, it may be UTM zone 17N?) I believe you are more expert in this area than I am, please point out if anything I misunderstood about it.

---

I have just update the Quick Start examples in the docs, please refer to it to check the main workflow by our dataset.

(Please press Ctrl+Shift+R to refresh if you have a local browser cache.)

For your applications, especially the grid spliting and inverse transformation matrix from raw image back to the DOM, I will find a time in this week to finish a similar demo for you based on our dataset.

[HowcanoeWang]

ortho = idp.GeoTiff("/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/Hidden_Little_03_24_2022.tiff")
Traceback (most recent call last):
  Python Shell, prompt 24, line 1
    # Used internally for debug sandbox under external interpreter
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/geotiff.py", line 21, in __init__
    self.read_geotiff(tif_path)
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/geotiff.py", line 34, in read_geotiff
    self.header = get_header(str(tif_path))
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/geotiff.py", line 562, in get_header
    raise KeyError("Can not find key 'GTCitationGeoKey' or 'PCSCitationGeoKey' in Geotiff tages")
builtins.KeyError: "Can not find key 'GTCitationGeoKey' or 'PCSCitationGeoKey' in Geotiff tages"

This has been fixed in da7493c

[bw4sz]

Let's keep this conversation, clearly alot is in active development. Let's start with the code. All files are in the dropbox link above, include the .files, and the .tiff. I cloned your main branch and pulled.

import easyidp as idp
print(idp.__version__)

2.0.0.dev3

ms = idp.Metashape("/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/Hidden_Little_03_24_2022.psx", chunk_id=0)
roi = idp.ROI("/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/example_bird.shp") 
img_dict = roi.back2raw(ms)

[shp][proj] Use projection [WGS 84] for loaded shapefile [example_bird.shp]

[shp] read shp [example_bird.shp]:   0%|          | 0/1 [00:00<?, ?it/s]
[shp] read shp [example_bird.shp]: 100%|##########| 1/1 [00:00<00:00, 212.31it/s]Traceback (most recent call last):
  Python Shell, prompt 22, line 5
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/roi.py", line 401, in back2raw
    out_dict = recons.back2raw(self, **kwargs)
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/metashape.py", line 259, in back2raw
    save_path = None
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/metashape.py", line 209, in back2raw_crs
    local_coord = self._world2local(self._crs2world(points_xyz))
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/metashape.py", line 112, in _crs2world
    return convert_proj3d(points_np, self.crs, self.world_crs)
  File "/Users/benweinstein/.conda/envs/DeepTreeAttention/lib/python3.8/site-packages/easyidp/metashape.py", line 1110, in convert_proj3d
    out = np.vstack([lat_m, lon_m, alt_m]).T
builtins.IndexError: index 2 is out of bounds for axis 1 with size 2

Looks like we are missing the z dimension. I have downloaded agisoft and I am familiarizing myself with it to export new files and align with the expectations of the API. Probably a better error message is required above. I remade the 3D model in a very quick and coarse way, but I still get the error above.

I think this relates to our larger conceptual mismatch that I think is worth discussing. I completely agree that you cannot recover a 2D position from a 3D point. However, I'm wondering about just multiplying the orthomosaic by the inverse transformation matrix for each camera position in 2D space. Clearly it will not be exact, but it may be roughly accurate to localize the bounding box.

Happy to do any legwork/testing, we have hundreds of .psx projects from UAV flights.

Here is that attached paper
01431161.2019.pdf

[HowcanoeWang]

just a quick response to this error:

Looks like we are missing the z dimension.

It is also required to export DEM/DSM as a source to getting z value (similar as mentioned in the paper, the z value is required no matter backword projection (dom2raw) or forward projection (raw2dom) ).

roi.get_z_from_dsm(dsm_path)

# will support getting z from point cloud soon
roi.get_z_from_pcd(pcd_path)

Thanks for your suggestions, i will make a better notice later for this like:

raise ValueError(
    "Seems current ROI does not have z values which is required for `back2raw()` function, "
    "have you tried `roi.get_z_from_dsm()` or `roi.get_z_from_pcd()` first?")

And for your worries about the accuracy. Here we just assume for most agricultural applications, the ground is flat so simply apply such inverse transformation should be acceptable (like the paper mentioned doesn't work for their cases). And your forstry canopy should be an interesting material to test whether it really works or not for not flat cases.

Apologize for the imcomplete docs and code functions. I am writing the demo for your applications. And will also try to write a script for you on the data you provided in this discussion.

[HowcanoeWang]

pictures for demo jupyter notebook

[HowcanoeWang]

In this weekend, I have tried my proposed "inverse transform matrix" workflow for your cases, you can access the jupyter notebook from here: https://drive.google.com/drive/folders/1VbQGwt2pWuoXUhx8i2tLBq18uLl8sDh6?usp=sharing

Firstly, I export the DEM and also make a grid (Hidden_Little_grid.shp) in your field:

Then I using the "136" grid as example, and do the backward projection to the closest image, and manually add 2 detection results as test data:

The agricultural cases are almost flat plane, when it comes to your cases (dramatic changes in the small area), seems get the problem you are concerned:

According to this pre-experiment, I come up with the following solution:

1. decrease the grid size to around just slightly larger than bird size, to ensure the "flat plane" have the correct height.
2. decrease the grid size to each pixel on DOM, making the "flat plane" as close to actual as possible Then interpolate the mapping table of pixel positions from DOM to raw image. Then look up the table to find the pixel coordinates of the bbox on the DOM

The solution 2 is almost the similar idea like the paper you shared (get the z for raw pixels). But in that paper, it does not consider the lens distortion effects. If we want to take it into consideration, we have to export the undistorted images by Pix4D or Metashape. Otherwise, we have to solve the inverse equation for lens distortion (personally feel quite challenging for it):

https://support.pix4d.com/hc/en-us/articles/202559089-How-are-the-Internal-and-External-Camera-Parameters-defined

[bw4sz]

Thanks for your work on this. I've been away and i'll have a look tomorrow morning. More tomorrow.

[bw4sz]

Great, i've reviewed this. I think this is really promising, even with the offset observed in the orange box. I think we should consider this always as a product for machine learning. I think it is reasonable to assume in most cases that the artifacts in the orthomosaic inhibit classification much more than detection. So rather than coming up with a perfect photogrammetry solution, we can also use the machine learning model to run on the ortho to match to the closest detection. This of course will not be perfect in cluttered scenes, but I think it will be highly valuable none the less.

Given that we have a reasonable way forward. Let me summarize to make sure I understand with some psuedo-code.

def raw2ortho(psx_path, dsm_path, dom_path, raw_detections):
    idp.Metashape(psx_path)
    grid = generate_grid()
    dom_parts = grid.crop(dom)
    grid_raw = ms.back2raw(grid)

   # This is the step I understand the least, we can either get the closest image, or ensemble the classification score from all matching images.
    closest_img = ms.sort_img_by_distance(grid_raw, grid, num=1)
    bbox = load_detections() # I see that libraries like geopandas are frowned upon in the package, so we'll need to create numpy index slices.
    # project points from DOM to selected image
    dom_coordinates = project_dom_to_raw()

    return dom_coordinates

we'll also want to formalize those plotting functions.

I can generate predictions for our object detection models in the raw and orthomosaic and then score the accuracy of the model. This would ask whether the potential increase in classification accuracy in the raw image is worth the potential drop in accuracy in the detection step.

Long term i'm happy to talk about wrapping this into a manuscript, or I can just use it in our downstream work. My lab at University of Florida (https://www.weecology.org/) is focused on open data science for ecological monitoring. We are highly collaborative, whatever works for you. I'm happy to work on a pull request and you can comment, or you can lead. I can supply more data and do the evaluations. Lots of options, obviously everyone is busy, always.

It remains absolutely remarkable how common I see this question among users of our object detection package and a number of threads on the agisoft forums (e.g https://www.agisoft.com/forum/index.php?topic=9404.0 or https://www.agisoft.com/forum/index.php?topic=2484.0 and many others), but that there isn't a more well defined solution/workflow. Strangely enough Agisoft has picked up our deepforest tool and encoded it in a GUI on their scripts page (https://agisoft.freshdesk.com/support/solutions/articles/31000162552-automatic-detection-of-objects-on-orthomosaic). I will be messaging the developer as we get further along.

[HowcanoeWang]

Glad that the current alternative approach meets your requirement. I could understand for photogrammetry experts, it may not be a challenging problem to get the precise position as the paper you share. But to be honest, it is more than I can handle at the moment. So I choose this alternative approach instead.

According to the pseudocode you posted here, I believe you understand correctly for the current workflow. Just a few more explanation for your comments:

1. Personally will prefer only using the closest image, I have also tried merging results from the closest 3 images in our agricultural pre-experiment, but other images often have a larger offset. (In your case, it will even get repeat detection caused by the birds moving). And for Metashape and other reconstruction software, they also pick the closest image to generate the orthomosaic.
2. For the load_detection() functions, personally prefer to avoid using geopandas which relies on the GDAL dependencies (sometimes hard to install on Windows by pip). Just using txt processing to get a numpy bbox should be perfect.

For the code contributing, apologize for the current incomplete documentation and API, it may waste you too much time to get familiar with the EasyIDP package by reading the source code. I could lead the implementation of the build-in generate_grid() and visualization functions when I have time. And very grateful if you can help us deal with the following functions:

1. load_detections() for bbox of DL products (seems different DL have different bbox formats? This may be tedious and challenging work). The easyidp/roi.py should be a good place to put this function like read_yolo_bbox(), read_coco_bbox(), etc. Then could merge them into the ROI class like ROI.read_bbox()
2. Since we only used one function/class from skimage.transform.ProjectiveTransform, it may not necessary to install the skimage dependices for just one function. Will it be possible to re-implement this function by NumPy instead (Copy and editing the skimage source code here)?

lastly, are you willing to give us permission to use the current bird dataset you shared as an official example for EasyIDP? This would be a great example/manuscript to demonstrate the solution/workflow for whom meet a similar question (and also welcome contributions to this official documentation). Then other users can access this dataset directly by bird = idp.data.BirdDataset() and try the raw2ortho() following the official documents.

When the EasyIDP v2 is well developed and documented, we may have an opportunity to collaborate on a software paper for this v2.0 integration. Personally believe using examples both from agriculture and ecology would be quite convincing.

[bw4sz]

You are welcome to use the data in any capacity.

Sounds good, i'll make a pull request. I don't think there is any reason to make multiple read_box() methods. Anyone who has the sophistication to make a machine learning model can also easily change bounding box formats. We could never cover all of them anyways and who knows, maybe a year from now, there will be a new one, common ones will be less used, etc. I think if this is going to straight numpy the best idea is

xmin, ymin, xmax, ymax, image_path, label

which matches torchvision's style. I can copy the source for ProjectiveTransform, that's fine.

Roadmap

1. Fork this repo and make a [WIP] pull request.
2. Create new functions
3. Add tests for new functions (fyi, we have script for github actions: https://github.com/weecology/DeepForest/blob/main/.github/workflows/Conda-app.yml).
4. Create tutorial on readthedocs.

I'm going to work on annotating some raw imagery to use as test data so I can compare classification performance in raw versus DOM.

[youngdjn]

I was very excited to learn about the EasyIDP project. I'm happy to see this progress toward projecting from raw images -> orthomosaics. I would find this extremely useful as well!

[HowcanoeWang]

We are now developing this function, not only just the bbox coordinates, but also will support replacing the raw image on the DOM to get a refined DOM result.

#59

[bw4sz]

I'm starting to spend more time on this project over the next few weeks. Nice new docs. I think some of the upgrades have made new assumptions about the file structure. Using the same data from above (#44 (comment)).

you now get

import easyidp as idp
import numpy as np
print(np.__version__)
print(idp.__version__)
ms = idp.Metashape("/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/Hidden_Little_03_24_2022.psx", chunk_id=0)
roi = idp.ROI("/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/example_bird.shp") 
img_dict = roi.back2raw(ms)

1.24.2

Python Shell, prompt 1, line 5
  ms = idp.Metashape("/Users/benweinstein/Dropbox/Weecology/everglades_species/easyidp/Hidden_Little_03_24_2022.psx", chunk_id=0)
File "/Users/benweinstein/.conda/envs/BirdDetector/lib/python3.9/site-packages/easyidp/metashape.py", line 107, in __init__
  self.open_project(project_path, chunk_id)
File "/Users/benweinstein/.conda/envs/BirdDetector/lib/python3.9/site-packages/easyidp/metashape.py", line 174, in open_project
  self.open_chunk(self.chunk_id)
File "/Users/benweinstein/.conda/envs/BirdDetector/lib/python3.9/site-packages/easyidp/metashape.py", line 246, in open_chunk
  chunk_content_dict = read_chunk_zip(
File "/Users/benweinstein/.conda/envs/BirdDetector/lib/python3.9/site-packages/easyidp/metashape.py", line 1178, in read_chunk_zip
  camera.sensor = sensors[camera.sensor_id]
File "/Users/benweinstein/.conda/envs/BirdDetector/lib/python3.9/site-packages/easyidp/__init__.py", line 74, in __getitem__
  raise IndexError(f"Index [{key}] out of range (0, {len(self.item_label)})")

builtins.IndexError: Index [1] out of range (0, 1)

which you can see when debugging on L1178 in metashape.py is because the sensor dictionary is indexed 0

    group_tags = xml_tree.findall("./cameras/group")
    if len(group_tags) == 0:
        for camera_tag in xml_tree.findall("./cameras/camera"):
            camera = _decode_camera_tag(camera_tag)
            camera.sensor = sensors[camera.sensor_id]
            photos[camera.id] = camera

sensors
<easyidp.Container> with 1 items
[0]	FC6540, DJI DL   35mm F2.8 LS ASPH (35mm)
<easyidp.reconstruct.Sensor object at 0x7f99923f0610>
sensors.keys()
dict_keys(['FC6540, DJI DL   35mm F2.8 LS ASPH (35mm)'])

but the camera.sensor_id is 1

camera.sensor_id
1

My gut reaction is that sensors is a dict with keys

sensors.keys()
dict_keys(['FC6540, DJI DL   35mm F2.8 LS ASPH (35mm)'])

but camera.sensor_id is an int. So that lookup won't work.

This was after I renamed the np.float -> float, which i'm going to make a PR for now.

Reminder the data is linked: #44 (comment)

[HowcanoeWang]

Probably I figured out the reason for this bird dataset.

For this metashape project, the doc.xml in Hidden_Little_03_24_2022.files\0\chunk.zip has the following record:

<sensors next_id="2">
    <sensor id="0" label="FC6540, DJI DL   35mm F2.8 LS ASPH (35mm)" type="frame">
      <resolution width="6016" height="4008"/>
      ...
    </sensor>
    <sensor id="1" label="FC6540, DJI DL   35mm F2.8 LS ASPH (35mm)" type="frame">
      ...
    </sensor>

The metashape mistakely duplicated the same sensor to two. And the easyidp assume the each sensor has different sensor label, so use it as the key. So in this case, the sensor 1 rewrite the sensor 0, for sensor object.

There should be a logic bug in idp.Container class which produces sensors object, I will take a look at it on this weekend.

[bw4sz]

Is there something we did in Agisoft to produce this, or is it expected? I can let my teammate know if we need to change our Agisoft workflow, we have 500+ .psx files.

[HowcanoeWang]

After I checking the xml file and its attribute, I think it is reasonable because I have found there are some slightly difference sensor attribute (cx, cy, k1 etc) between two sensors. And most of the images used the sensor 0, while only DJI_0176 and DJI_0190 used the sensor 1.

So here is my hypothesis: you aligned the photo successfully except DJI_0176 and DJI_0190, then you optimized the camera to ensure all images were aligned. In this step, the sensor attribute was changed for the two images and metashape labeled them as new sensor.

To handle this case, I would prefer fixing easyidp to handle this problem #86, rather than forcing users to adjust their workflow.

[HowcanoeWang]

9d4929c should fix this, plus the demo jupyter into docs https://easyidp.readthedocs.io/en/latest/jupyter/forward_projection.html

[bw4sz]

Yes, fixed. Running tutorial now. Thanks!

…

On Fri, Mar 31, 2023 at 7:53 PM Howcanoe WANG ***@***.***> wrote: 9d4929c <9d4929c> should fix this — Reply to this email directly, view it on GitHub <#44 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJHBLECSIQPNTJNGYAMLUDW66KCBANCNFSM6AAAAAAQEEPM3U> . You are receiving this because you authored the thread.Message ID: <UTokyo-FieldPhenomics-Lab/EasyIDP/repo-discussions/44/comments/5494810@ github.com>

-- Ben Weinstein, Ph.D. Research Scientist University of Florida http://benweinstein.weebly.com/