OirthirSAT / image-processing-pipeline

full processing for extractions of vectors from coastlines
0 stars 0 forks source link

Determining File Interfaces Marching Squares #22

Open lewismcnish opened 1 week ago

lewismcnish commented 1 week ago

Overview

Determine the file type required for Marching squares to run successfully, how is this going to fit into the pipeline, as well as what output marching squares provides to continue processing (should be a vector type file out as this is end of processing) Ideally we would have .tif files (or alternative raster file type) as input.

Requirements

(In order of importance)

  1. Determine input file type of Marching Squares
  2. Adjust Marching squares algorithm where possible to accept a generic raster file (this should already be a .tif (i.e. no changes))
  3. Determine the output file type of Marching Squares
  4. Adjust Marching Squares where possible to output a vector file type (If not make issue for Lewis to review this and create Plan of action)
  5. Record the size of output file ideally <5 Mb

Definition of Done

  1. Marching Squares file interfaces defined and where possible in the most convenient form
  2. Record file interfaces for Marching Squares in the Payload Software Configuration doc (Sharepoint link in references)

Resources

Screenshot 2024-11-04 at 15 56 55

Sharepoint link to Payload Software configuration:

https://gla.sharepoint.com/:w:/s/OirthirSAT2/EQIEpuKftlpHiL21AwJBt_cB-ltap1qgXgBjaYQgnKIXGA?e=JfjDT9

JazzyMaxine commented 5 days ago

For reference, cv2.imread() can accept these filetypes as input: docs

Our decision on file interfaces may depend on what we learn in Thursday's imaging software demonstration, I wonder what file type the onboard camera will produce, whether it will be discrete or just a datastream etc. Their general advice will be helpful as well.

One thought: Each of our current pipeline steps computes cv2.imread(), so it might make sense to internally represent the image as arrays and do an initial processing of .tif -> internal representation and a final processing of internal representation -> output type instead of re-processing our representation into a .tif and back into internal representation for each step. I'm not committing a lot of thought to this right now because I think that Thursday's demonstration will help and might take us in a completely different direction.

Ditto for #21 #23