-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SAHI in workflows
#574
SAHI in workflows
#574
Conversation
…about detections metadata
…rvation of all required properties
We also need to decide on reasonable defaults for slice size. I bet that 640 may be better than 320, but this is only gut feeling based on assumption that size of input for model is more likely to be 640 than 320. |
We need this UI change to merge this, or you mean in general this is a pattern we should move towards to make this easier / better UX? Not a trivial UI change in terms of graph/viz editing state I think. Could we have the individual blocks in addition to a block that handles all of it for ease of use / most common scenario? |
I meant changes in UI in the future, but I bet now it will be confusing if we added the blocks from this PR - I bet noone would know how to use it.
|
Agree that having 3 blocks will be very confusing from a UI perspective. Couple questions/thoughts:
However, the ideal UX is a much bigger lift, we can start providing value to users with the individual blocks + a blog post to explain how to configure them |
Re: @EmilyGavrilenko comment:
|
resolution_wh=resolution_wh, | ||
) | ||
re_aligned_predictions.append(re_aligned_detections) | ||
overlap_filter = choose_overlap_filter_strategy( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we be merging / detecting duplicates each time we add boxes rather than once at the end? Maybe that doesn't make a difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should do it at the end, otherwise we are running unneeded computations I am afraid, besides - this is the implementation of sv.InferenceSlicer
that I hope will become part of public interface later on, such that we could replace our duplicate code with sv
if SCALING_RELATIVE_TO_PARENT_KEY in detections.data: | ||
scale = detections[SCALING_RELATIVE_TO_PARENT_KEY][0] | ||
if abs(scale - 1.0) > 1e-4: | ||
raise ValueError( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what s an example of this happening?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you bring operation of bboxes scaling in between model and stitch, which you should not be doing, but you can through UQL
@classmethod | ||
def describe_outputs(cls) -> List[OutputDefinition]: | ||
return [ | ||
OutputDefinition(name="crops", kind=[BATCH_OF_IMAGES_KIND]), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think output should be named slices
instead of crops given other naming on block and properties
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
result = execution_engine.run( | ||
runtime_parameters={ | ||
"image": [license_plate_image], | ||
"overlap_filtering_strategy": "none", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"overlap_filtering_strategy": "none", |
not used in workflow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
np tests for actual block functionality. I think its OK. since its basically tested in test_workflows_with_sahi.py
but maybe add a comment to point to that file in case someone comes in here to understand how this block should behave
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's rename slider output to slices
instead of crops
but otherwise looks great!
Description
In this PR we are adding SAHI to
workflows
in the following way:supervision
to avoid fragile integration on private interface)😄 PROS of the approach:
😢 CONS of the approach:
@LinasKo could u please take a look at the implementation to verify that usage of
supervision
components is as intendedNUANCES (please acknowledge carefully)
stitch block requires
reference_image
- which is the image used to create crops, which will create the following schema:Initially I wanted to avoid this additional parameter
reference_image
- but we need it if we wanted to maintain notion ofparent_id
insv.Detections
- which is used by such blocks asDetections Consensus
and can ensure that wheneverwe are blending is coming from the same image - which is helpful to prevent bugs. I tried to remove the problem but that lead me to
lineage
property being added into Execution Engine entity causing partially breaking change to EE which I wanted to avoid (probably impact would be low, as there are barely no custom plugins created), but stopped the work in this direction as this is labour intensive and potentially not needed if you like the approach. If you don't we need to:lineage
property (see commits in the PR which were reverted)sv.Detections
supervision#1226In my opinion this is discussion about tradeoffs:
both approaches have pros and cons - I would like to know your opinions on that matter
IMPORTANT
SAHI is not always good approach - please try to
plt.imshow()
visualisations in integration tests running on cars images to see how improper use is going to lead to terrible results - we should mindfully guide users towards the feature, otherwise people will not like that.Type of change
Please delete options that are not relevant.
How has this change been tested, please provide a testcase or example of how you tested the change?
Any specific deployment considerations
For example, documentation changes, usability, usage/costs, secrets, etc.
Docs