Skip to content
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

Merged
merged 14 commits into from Jul 25, 2023
Merged

Allow setting sketch color default #4979

merged 14 commits into from Jul 25, 2023

Conversation

aliabid94
Copy link
Collaborator

@aliabid94 aliabid94 commented Jul 20, 2023

Set brush_color via gr.Image(brush_color="#FF0000").

Looks like this:

Recording 2023-07-24 at 05 54 26 (1)

@vercel
Copy link

vercel bot commented Jul 20, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
gradio ✅ Ready (Inspect) Visit Preview Jul 25, 2023 6:32pm

@gradio-pr-bot
Copy link
Contributor

gradio-pr-bot commented Jul 20, 2023

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

@gradio-pr-bot
Copy link
Contributor

gradio-pr-bot commented Jul 21, 2023

🎉 Chromatic build completed!

There are 0 visual changes to review.
There are 0 failed tests to fix.

@gradio-pr-bot
Copy link
Contributor

gradio-pr-bot commented Jul 21, 2023

🦄 change detected

This Pull Request includes changes to the following packages.

Package Version
@gradio/app minor
@gradio/image minor
gradio minor
  • Maintainers can select this checkbox to manually select packages to update.

With the following changelog entry.

Allow setting sketch color default

Maintainers or the PR author can modify the PR title to modify this entry.

Something isn't right?

  • Maintainers can change the version label to modify the version bump.
  • If the bot has failed to detect any changes, or if this pull request needs to update multiple packages to different versions or requires a more comprehensive changelog entry, maintainers can update the changelog file directly.

gradio/components/image.py Outdated Show resolved Hide resolved
@@ -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
Copy link
Collaborator

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?

Copy link
Collaborator Author

@aliabid94 aliabid94 Jul 24, 2023

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

Copy link
Member

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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

@dawoodkhan82
Copy link
Collaborator

Tested and looks good! Should we eventually also make the alpha of the brush settable?

gradio/components/image.py Outdated Show resolved Hide resolved
@aliabid94
Copy link
Collaborator Author

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.

Copy link
Member

@pngwn pngwn left a 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.

@abidlabs
Copy link
Member

Should we eventually also make the alpha of the brush settable?

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 brush_opacity parameter (default can be 0.7 as in this PR)

@aliabid94
Copy link
Collaborator Author

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

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.

@abidlabs
Copy link
Member

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.

@aliabid94
Copy link
Collaborator Author

ok done, added mask_opacity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants