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

Pre-Cropping #27

Open
K-Y-Johnson opened this issue Jul 23, 2020 · 32 comments
Open

Pre-Cropping #27

K-Y-Johnson opened this issue Jul 23, 2020 · 32 comments
Labels
bug Something isn't working

Comments

@K-Y-Johnson
Copy link

We are using your widget to create square avatars. When we do so, it pre-crops the original image.

Here is an image.

Given this original image, we placed it inside your example app, changing only line 106 to reference this image (also adding it as an asset in the pubspec.yaml).

When we run the app and set a 1:1 aspect ratio, which is the functionality we want, here's what we end up with. We can't see the person of interest because of the pre-crop that occurs due to the fit: BoxFit.cover.

Below is the desired result.

@xclud
Copy link
Owner

xclud commented Jul 23, 2020

Crop defaults to center of the image when the aspect ratios are not equal. You'll never know where in the image your users want to select and crop. What if the user wants to crop the horse. Or even the flower? How do you know? You may not predict what user wants.

@xclud
Copy link
Owner

xclud commented Jul 23, 2020

We can't see the person of interest because of the pre-crop that occurs.

It's not your task to select the human face. Users should do it.

@K-Y-Johnson
Copy link
Author

I agree. Users should be able to select whatever they want for their avatar, and it's not the programmer's job to select the human face.

The issue is that due to fit: BoxFit.cover, the image is pre-cropped, and the user is literally unable to select anything that isn't shown in the image below. The human figure isn't able to be shown, as the data isn't there since it was cropped out.

The image is exactly the same as shown in my previous message, simply zoomed out.

@xclud
Copy link
Owner

xclud commented Jul 24, 2020

The issue is that due to fit: BoxFit.cover, the image is pre-cropped, and the user is literally unable to select anything

Can't you pan the image?

Where did the last screenshot come from? I mean the one with black bars.

@K-Y-Johnson
Copy link
Author

No, we are unable to pan the image. That data has been cropped off.

The last screenshot came from me zooming out with two fingers and holding the image while I took a screenshot. After I released the image, it snapped back to look like the second image in my first post.

@K-Y-Johnson
Copy link
Author

We have run this situation on iOS simulator, Android emulator and iPhone Xs, and the results are the same.

@0xshipthecode
Copy link

I see the same problem, using BoxFit.contain instead of BoxFit.cover seems to solve the problem. The Image is shown with "missing parts" if the Controller aspect ratio is different from image aspect ratio. However users can then achieve cropping of any part. Hope this helps @K-Y-Johnson

@K-Y-Johnson
Copy link
Author

Thank you for your help, @vejmelkam.

We did discuss this possible solution in #24, however it then results in showing the user "missing parts" or black bars, which the user is then able to crop into their image. Allowing the user to do this is not part of our desired functionality, though it is a possible workaround.

@nwparker
Copy link

nwparker commented Nov 19, 2020

@xclud , here is a video demonstration of the issue:

crop_cutting.zip

In this case, I'd like to crop the image to 16:9, but I want to capture the upper portion of the image. However, after selecting a 16:9 crop aspect ration, I am unable to pan and therefore unable to capture the upper portion of the image.

Note:
I've tried setting fit: Boxfit.contains as suggested above on my image to no avail

@xclud
Copy link
Owner

xclud commented Nov 19, 2020

@nwparker Thank you. Now I am able to reproduce the bug. Will let you know when I fix this. Contributions are welcome :)

@nwparker
Copy link

@nwparker Thank you. Now I am able to reproduce the bug. Will let you know when I fix this. Contributions are welcome :)

I haven't had luck fixing this altogether, but it turns out out switching to BoxFit.contain vs BoxFit.cover (as mentioned above) does actually change the situation ( nwparker@ede6939 )

However, it's not quite right as it allows cropping of areas outside of the image

@SF-Simon
Copy link

@nwparker Thank you. Now I am able to reproduce the bug. Will let you know when I fix this. Contributions are welcome :)

I haven't had luck fixing this altogether, but it turns out out switching to BoxFit.contain vs BoxFit.cover (as mentioned above) does actually change the situation ( nwparker@ede6939 )

However, it's not quite right as it allows cropping of areas outside of the image

We can't simply change this parameter. I think we should change the original zoom factor, which should be determined by the size of the image and the target clipping size.

@rich-j
Copy link

rich-j commented Nov 24, 2020

@HeebeLee correct that scaling should be adjusted too. See the comment in related closed issue #24 (comment)
that provides one workaround:

final imageAspectRatio = image.width / image.height;
final minScale = imageAspectRatio < 1.0 ? 1 / imageAspectRatio : imageAspectRatio;
cropController.scale = minScale;

This is not a complete solution since it doesn't constrain the user's panning/zooming to not enter the "empty" image parts.

@momoDragon
Copy link

No, we are unable to pan the image. That data has been cropped off.

The last screenshot came from me zooming out with two fingers and holding the image while I took a screenshot. After I released the image, it snapped back to look like the second image in my first post.

Hi, I am still facing this issue. Any fix?

@xclud
Copy link
Owner

xclud commented May 12, 2021

@momoDragon I am rewriting a part of calculations at the moment. Will publish a new version when done. This bug is over a year old now and we should get rid of it.

1 similar comment
@xclud
Copy link
Owner

xclud commented May 12, 2021

@momoDragon I am rewriting a part of calculations at the moment. Will publish a new version when done. This bug is over a year old now and we should get rid of it.

@amirucefi
Copy link

@momoDragon I am rewriting a part of calculations at the moment. Will publish a new version when done. This bug is over a year old now and we should get rid of it.

I'm waiting to solve this issue and enjoy more,
I have same issue that cropper select the center of image and I can't select another part of image to crop.
thanks

@michaldev
Copy link

michaldev commented May 31, 2021

My cat needs help.
https://vimeo.com/557199490

@xclud
Copy link
Owner

xclud commented May 31, 2021

@michaldev Sorry for the inconvenience. My own cat needs help too!. This issue is blocking version 1.0 release and i hate this.

@margorski
Copy link

@xclud Hello is there any progress on that bug?
Is there any branch you are working on? I could try to help you with that if you are busy.

Cheers

@xclud
Copy link
Owner

xclud commented Aug 3, 2021

Hi @margorski,

I appreciate your contribution. I am working on hotfix-crop-bug branch.

@jasonJamEther
Copy link

I really appreciate the work that has been done on this package. I recognize you are doing all this work out of good will. I just wondered if any progress has been made on this issue?

@margorski
Copy link

Hello @xclud
I did a fix for that on the forked repository. Here is the pull request: #71

I admit that I didn't do any heavy tests. Using the example app I checked all aspect ratios and it looks that it works.
One thing I changed is a clamping area for the rotated pictures. If I remember correctly in the previous implementation it was clamping panning of the image to the inside of the picture. Now I allow panning on boundaries of the rotated image. Take a look at pictures to see how it works:
image

It could be changed but it is suitable for my project so I will keep that on the forked repo.

In the next day, I will be integrating that into our app so if I will encounter any problems I will add fixes on the branch. For now, you could take a look if that is anything that will work for you.

@margorski
Copy link

Still need some work with vertical images so not ready yet :)

@margorski
Copy link

Ok, it looks like it is ready now. Review and see if that is a good solution to merge into your library.

@xclud
Copy link
Owner

xclud commented Nov 17, 2021

@margorski Thank you for the great job on this bug. You definitely make a a lot of people happy and you will make the package go to version 1.0. I appreciate your work on behalf on everyone using this package.

@FerBueroTrebino
Copy link

Hello @xclud thanks for the awesome work!

Do you know when it will be available version 1.0 with this bug fixed?

@lukehutch
Copy link

In case anybody needs a ready-to-go solution, I manually applied all the outstanding PRs #66, #68, and #71, to my own fork of this repo (the PRs don't apply cleanly, because the main branch has changed too much).

https://github.com/lukehutch/flutter_crop

This solves the problem for me (at least with rotation disabled, I haven't tested with rotation enabled).

@lukehutch
Copy link

Actually I spoke too soon -- @margorski your PR #71 doesn't work when cropping a 16:9 aspect ratio photo using aspectRatio: 9/16. You can't select all the way to the sides of the image, and you can select a black area above and below the image.

@lukehutch
Copy link

@margorski I fixed the issue in your PR, but there were more issues with rotation, e.g. the bounding box calculation and minimum scale calculations were wrong.

Since I don't need rotation, I just need a working crop widget, I removed rotation support from my fork (linked in a previous comment). That version is now fully functional. Somebody else is welcome to take that version and add rotation back in, if they're game to wrap their mind around the needed trignonometry.

@tomasweigenast
Copy link

Lol, 2024 and still no fix

@ismail-mufin
Copy link

@lukehutch 2024 and your fork is working great! Thanks a lot mate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests