-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Allow setting sketch color default #4979
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
All the demos for this PR have been deployed at https://huggingface.co/spaces/gradio-pr-deploys/pr-4979-all-demos You can install the changes in this PR by running: pip install https://gradio-builds.s3.amazonaws.com/3f8c210b01ef1ceaaf8ee73be4bf246b5b745bbf/gradio-3.38.0-py3-none-any.whl |
🎉 Chromatic build completed! There are 0 visual changes to review. |
🦄 change detectedThis Pull Request includes changes to the following packages.
With the following changelog entry.
Maintainers or the PR author can modify the PR title to modify this entry.
|
@@ -276,6 +282,10 @@ def preprocess( | |||
|
|||
if self.tool == "sketch" and self.source in ["upload", "webcam"]: | |||
mask_im = processing_utils.decode_base64_to_image(mask) | |||
|
|||
if mask_im.mode == "RGBA": # whiten any opaque pixels in the mask |
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 don't follow this. Can you explain what's 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.
yep, so previously in the frontend, whenever a user drew a mask, we were drawing it twice - once on the visible layer directly on the image, and then again on a hidden layer called "mask", which instead drew with a white brush on a black background. This mask layer was what was getting sent to the backend on submit.
I simplified the frontend so that there is a single mask layer, now visible, that hovers over the drawing. A user is no longer drawing directly on the image, but instead on this visible mask layer. On submit, we send this mask layer. However, this mask layer is no longer the white on black image of before - it has opacity and may be whatever color that brush_color has been set to. So now we convert this mask layer into the B+W mask of before in the backend with these lines of code.
We support "backwards compatibility" in case someone uses a client, with if mask_im.mode == "RGBA":
, because previously masks were only RGB.
cc @pngwn for context to the frontend changes
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.
Are we certain that this conversion is always accurate (going from colours to b+w, especially since the sketches are antialiased)? Masks are typically alpha layers and lack any colours, I'm curious about why we would ever want a mask layer with colour.
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.
The mask layer only has color because that's how that canvas is rendered now, as a color on a transparent background. I assumed the antialiasing would manifest in the alpha, as in the smooth edges would have an alpha between 0 and 255, which would get translated to some gray between 0 and 255 in the backend logic where we take the alpha value and set it as the R, G, and B values. Will confirm if this antialiasing works.
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.
Confirmed that antialiasing still works - there are values between 0 and 255 at the edges of the mask
…gradio into sketch_color_default
Tested and looks good! Should we eventually also make the alpha of the brush settable? |
I don't think there's a need for this. We can see if we get any requests. |
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.
Looks go to me! tested and everything seems to work great! Thanks for tackling this one @aliabid94! Maybe you love the Image component as much as I do now.
Sorry for the late reply, but I agree with @dawoodkhan82 on this. We're making a breaking UI change with no way to for users to restore the original behavior. I would add a |
Disagree - there's slight opacity to a mask, which makes it easier to use. We are just going to have argument bloat if we add a configurable argument just for every minor UI change we've made. |
I agree that for most use cases that come to mind, setting the mask opacity to 0.7 is a good thing. However, with hundreds of thousands of gradio apps, there's a good chance that someone is using the mask in a different way than we imagine and wants the mask to be fully opaque. Upgrading gradio would break their demo without offering them a way to fix it. We've seen this problem several times already (changing the chatbot bubbles, making "enter" submit an Interface, etc.). I really think providing arguments to ensure backwards compatibility outweighs the concern of argument bloat. |
ok done, added |
Set brush_color via
gr.Image(brush_color="#FF0000")
.Looks like this: