Crop zone exceeds natural image size

[orangewarp]

In certain scenarios, the crop data object is returning coordinates larger than the image itself. See image example:

Thus, when passed to a server we receive an error like this: {"code":142,"error":"[\"Crop height should be in the range [1, height - top].\",\"Crop height should be in the range [1, height - top].\"]"}

[fengyuanchen]

Thank you very much! I will fix it soon!

[orangewarp]

It's a great tool. :-) Appreciate your work.

On Sunday, July 6, 2014, Fengyuan Chen notifications@github.com wrote:

Thank you very much! I will fix it soon!

— Reply to this email directly or view it on GitHub https://github.com/fengyuanchen/cropper/issues/34#issuecomment-48103423.

[fengyuanchen]

Thanks~ It's OK now.

[orangewarp]

Nice. I've been testing it and so far no errors. Heh heh. Math.round vs Math.floor. ;-)

[orangewarp]

Guess I spoke too soon. :-)

There are still some edge cases where the height and y2 can exceed the size of the original image. The issue seems to be with the transformData() function. The cropper data passed in is correct and from first glance, the passed in ratio multiplier seems good too. But at the most extreme crop areas (cropper size is maxed out in one dimension) the end return of the transformData() function can slightly exceed the original image size. We're talking 1 pixel per ~ 900. I've only seen this happen on the y dimension although you might want to check the x as well.

This might be solved by having a validation sub-routine to make sure the boundaries are within the naturalHeight and naturalWidth. If a dimension (or both) exceed, data will reduce the exceeding crop dimension by the difference and reduce the other proportionally, taking the aspectRatio in account.

See console output with various console.log() markers from the source.

[fengyuanchen]

Well, I'll check it carefully. Thanks again~

[nbibler]

It appears as though something since 14c20fec973cc960050fb8d17b746d6fefad9bf6 has negatively affected setData. It appears to be an internal rounding error causing the results of getData to be different from the given x1, y1, width, and height in setData. Sometimes it's off by 1px, sometimes 2-3px. It can be seen on the demo page, as well.

Here's a soundless video demo showing how changing any of the setData values fail to properly set the cropper location or size to those given values:

http://screencast.com/t/bP1FlBcq

[fengyuanchen]

@nbibler Thank you. I know, It's the reason of using Math.floor to transform the data. I will try to improve this as soon as possible.

[orangewarp]

@fengyuanchen , Is the Math.floor or rounding etc. necessary at all? I was looking at the output results of using jcrop for comparison and they're sending pure decimal values as data crop output.

I went ahead and removed all rounding / flooring from the the cropper code and it seems to work just fine. Images and full height crops that were giving me errors before on my server seem to have disappeared.

Without any number adjusting cropper will output stuff like this...

Object {x1: 95.99999999999997, y1: 0, x2: 1920.0000000000002, y2: 1824.0000000000002, width: 1824.0000000000002…}

Which is being happily accepted by the back-end. I don't know if most server-side image processing takes decimal points as input but if this is indicative of the standard - maybe the number adjusting can be removed or at least, an option?

[fengyuanchen]

@orangewarp Fine! I will try to improve this in the next version.

[fengyuanchen]

@orangewarp I have improve this on v0.4.0, and the difference between input and output is less than 2px.