Additional "eraser" feature

[monsieurtanuki]

In our project we now use the crop tool for receipts. In some cases receipts contain user data inside the cropped area, and we should not display/upload it. With an eraser button, the user would be able to erase part of the image. While still cropping it.

[deakjahn]

Sorry but this package does no image manipulation at all. It just gives the rectangle, as you know. A long shot but maybe a plugin approach that can manipulate the image separately but I really don't know if it's warranted...

[monsieurtanuki]

@deakjahn What would be the solution then? I can imagine

• Stacking an eraser widget on top of CropImage, where the user bars manually what is to be hidden
• but then, getCroppedBitmap will return an immutable image of the cropped zone, and I'll have to copy again that cropped area in order to apply the eraser

What about adding an optional additionalDrawing parameter in getCroppedBitmap, something like void Function(Canvas)?:

additionalDrawing: (Canvas canvas) {
  final Paint myPaint = Paint()
    ..strokeWidth = SmoothBarcodeScannerVisor.STROKE_WIDTH
    ..color = Colors.white
    ..style = PaintingStyle.stroke;
  canvas.drawPath(myPath, myPaint);
}

[monsieurtanuki]

As you see, the impact would be limited on crop_image, and that would look like this:

[monsieurtanuki]

Working on the subject. cf. https://github.com/openfoodfacts/smooth-app/issues/5301 It looks like the only change would be an additional optional CustomPainter in getCroppedBitmap.

[deakjahn]

I can't yet see how that would be used. I mean, croppedBitmap() is purely a convenience function that's in the package mostly to avoid people always asking the first question of 'but what do I do with the crop rectangle when done'? The package itself doesn't use it and you're never forced to use the function from the package, you can process your crop rectangle any way you see fit. So why would it be advantageous to integrate it into the cropper?

[monsieurtanuki]

The fact that I need this feature in a concrete use-case shows that i's not just a theoretical "what if / just in case" feature request.

You're right if you're talking about a fixed crop widget: a Widget with an input file, a crop grid and a "save cropped image" button. No need to change that.

But it's already a bit different now, with the controller and separate "rotate" widgets: developers can use their own buttons and their own icons, put them where they want, or even not display any "rotate" buttons at all.

If we're rather talking about a crop toolkit we keep the CropImage as a turnkey solution, but provide flexibility.

[deakjahn]

If you think that it's only an added callback, sure, go ahead, try it.

[monsieurtanuki]

Thank you @deakjahn! I haven't finished my code and tests yet, but on the crop_image side that will be just a CustomPainter? parameter here and there. I keep you posted.

[deakjahn]

Implemented by https://github.com/deakjahn/crop_image/pull/53.