Closed taoeffect closed 2 years ago
I created mockups to solve this issue. Please take a look at them here.
When doing this, we should also try to solve the issue #771
I'm removing myself from this issue, it's ready to be picked up by either @sandrina-p or @pieer !
Hi @taoeffect, Since I started working on this issue last week and have made a good progress so far, but as some requirements of this task involves relatively advanced work to be done, thought it would help if we split the work into two chunks and below is my suggestions for it. :)
Chunk 1 ] Create the editor modal and add zoom in/out functionality.
GroupName.vue
, GroupSettings.vue
)Chunk 2 ] Adding various event handlers to the editor canvas
To sum up, after chunk 1, we will be able to zoom in/out on the target image by using the slider & buttons on the editor and export the outcome as the avatar image but can't move the image around the canvas and can't perform these using various mouse and touch events yet. chunk 2 will be about implementing those "can't" in the above sentence.
Hope it sounds good. and pls let me know also if you have any suggestion on these.
Thanks.
Hi @leihla @taoeffect , While working on this issue, spotted something that needs discussion from you guys.
(pls correct me if I'm wrong but) currently the background color of this clipping circle is #F5F5F5 with the opacity 0.5 according to the figma.
But the circle is hardly noticeable when the image color is similar to that as you can see from below screenshot.
Do you think we would maybe want to use a different color or draw a border for the circle? Or would you have any other idea to cope with it?
Thanks,
Summarizing discussion from call with @SebinSong: because clipping it as a circle and saving as a transparent PNG in some cases actually increases the file size, while also being significantly more complicated to implement, we decided to instead simply use clipping square, and save the image as a JPG. The frontend already handles clipping the saved images as a circle.
Regarding your other comment:
Hope it sounds good. and pls let me know also if you have any suggestion on these.
Yes we can split it into two PRs if you'd prefer. Only comment is to use 512x512 images instead of256x256 because of high-DPI (retina) screens.
Hi @taoeffect, There is a couple of things that need your input. :)
per your suggestion from the weekly call of using css-filter to make the clipping circle more recognisable when the image color is similar to that of the clip area, I have tried various filters and decided that applying a combination of gray-scale() and blur() filters looks the best. here is a video record of me demonstrating it for you to be able to see what it looks like now.
Q1. Does it look good for you as well? (pls let me know if you have better idea)
We have also discussed about "clipping it as a circle and saving as a transparent image" in the weekly call, and decided to proceed with square image because of the complexity of achieving this. I actually have done some more research on this since then, as I thought this can be crucial for reducing the edited image file size and managed to make it work, as you can see from the last part of the video of me opening the downloaded image. (BTW, image being downloaded after hitting 'save' button is actually not a requirement of this task but rather an action I inserted for a testing purpose, to check what the final image looks like)
Q2. Do you think we can go with this being implemented(if there is no issue found regarding it)?
In summary, the generated image specs are below:
Does this sound good?
Thanks,
@SebinSong That looks really great!
The only question / concern that I have is this:
Circular shape with transparent background.
My understanding was that JPGs don't support transparent backgrounds? Am I mistaken about that?
Also, another concern is that if we clip it as a circle when saving the image, and then clip it as a circle again later on when displaying it in the UI, there might be some non-overlap between the picture circle and the additional live-clipping, i.e. some exposed transparent pixels if the additional display clipping is off somehow. This wouldn't happen if it was saved as a square.
Is there any reason we can't save the image as a 512x512 square anyway? I'm not suggesting that you need to change any of the work you've done with the circle and filter that's applied in the editor, as it will still show how the image will be displayed in the app - just that the image that gets saved is saved as a square instead of a circle.
@taoeffect
Also, another concern is that if we clip it as a circle when saving the image, and then clip it as a circle again later on when displaying it in the UI, there might be some non-overlap between the picture circle and the additional live-clipping, i.e. some exposed transparent pixels if the additional display clipping is off somehow.
Yes, no problem with generating the square image as the editor output in that case. :) Thanks for confirming.
Q1. Does it look good for you as well? (pls let me know if you have better idea)
Hey @SebinSong, your proposal to fix the background color when you looks good to me, the blur adds a nice touch to it. In this scenario do you still want a new color for the overlay?
Also, not sure what you and @taoeffect decided regarding the clipping to circles for the images, but in terms of flexibility, if in the future we decide to go to square profiles instead of circles, would the clipping solution still work?
Hi @leihla, If the applied filter looks good for you both, I believe we don't need further design input for differentiating the colours. and we came to an agreement that the generated image will be a square to prevent some edge cases that the circle-shaped image could occur such as below(commented by Greg above).
there might be some non-overlap between the picture circle and the additional live-clipping, i.e. some exposed transparent pixels if the additional display clipping is off somehow
thanks,
Problem
For uploading both the group profile image and the user profile image, there are multiple problems:
Solution
The end result is that all profile pictures (both group and user pictures) should be set to some constant values predefined in the app (e.g. let's say 512x512).
The point of the profile picture editor is to take as input [USER PICTURE] and produce as output => [CROPPED AND SCALED USER PICTURE OF SIZE 512x512], that is then the final picture that is actually uploaded to the server.
The profile picture editor needs to allow the user to both scale and move the picture, so that they can pick the section of the photo that they want to be their profile picture. It should also allow them to maybe select a background color to fill in any gaps (if there are any) that are created as a result of moving+scaling the photo in such a way that its edges are visible in the final cropped section.
EDIT: there is a related issue #1132 - which is necessary to close before implementing this issue. It's just about scaling the images - not about the UI for a profile picture editor.