You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This isn't anything critical, but could allow performance improvements.
Currently, each preprocessed image has its own model (Feature, Registered, Jacobian, Segmented). In reality, these are mostly the same, with Feature and Registration each having an extra field. However, having them separated in this way makes logic and queries complicated, as we often want "all preprocessed images", which means asking for all of each image separately, and then combining them.
In reality, these models could be combined into one "PreprocessedImage" model, with a type field that is one of Feature, Registered, Jacobian or Segmented. We'd also want a metadata field to contain the extra type specific parameters that we'd need (Feature and Registered). We could even set up database constraints to ensure that they exist.
The text was updated successfully, but these errors were encountered:
This isn't anything critical, but could allow performance improvements.
Currently, each preprocessed image has its own model (Feature, Registered, Jacobian, Segmented). In reality, these are mostly the same, with Feature and Registration each having an extra field. However, having them separated in this way makes logic and queries complicated, as we often want "all preprocessed images", which means asking for all of each image separately, and then combining them.
In reality, these models could be combined into one "PreprocessedImage" model, with a
type
field that is one ofFeature
,Registered
,Jacobian
orSegmented
. We'd also want ametadata
field to contain the extra type specific parameters that we'd need (Feature and Registered). We could even set up database constraints to ensure that they exist.The text was updated successfully, but these errors were encountered: