imageWithPerspectiveCorrectionFromQuad scale problem.

[Maxtws]

I noticed an issue with UIImage scale and "imageWithPerspectiveCorrectionFromQuad". If I pass an image with scale factor 3.0f (iPhone6 Plus) it crops only portion of an image. As far as I traced the rects it appears to act weird here:

(Line 164:) UIImage *correctedImage = [self imageWithTransform:transform anchorPoint:CGPointZero];
(Line 165:) UIImage *resultImage = [correctedImage imageByCroppingToRect:destinationRect];

Here, imageWithTransform returns an image with scale 1.0f (so its size in points = size in pixels) and destinationRect is still in points. So the result image is 1/3 upper part of the source image.

Of course, you can always transform your @3x image into @1x by drawing it to image context with scale 1.0 and triple source size. However in situation where you're really low on available memory this could be a hussle.

[hfossli]

Yep, I know that's a problem on the API level of our framework. Pull requests are welcome.

[hfossli]

Sorry for the delay btw. I've been sick lately and haven't had the energy to do much.

[Maxtws]

No worries! I hope you feel better now.
I’ll try to arrange a pull request as soon as I get a spare moment.
Thank you!

On Apr 15, 2016, at 3:32 PM, Håvard Fossli notifications@github.com wrote:

Sorry for the delay btw. I've been sick lately and haven't had the energy to do much.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #37 (comment)

[hfossli]

Thank you! It may take some time to recover.

Anyways if you are eager to do this and want even better result we could throw our handwritten resampler (AGKTransformPixelMapper) out the window and replace it with CoreImage's own perspective correction api. http://flexmonkey.blogspot.no/2016/04/a-look-at-perspective-transform.html Would be awesome and would probably make it both faster and with a lot higher quality! A lot of people would benefit from this.

Remember many people rely on the API so it is wise to mark public methods deprecated. That way we don't need to create a 2.x version of this framework. I like this way of deprecating https://github.com/ReactiveCocoa/ReactiveCocoa/blob/v2.5/ReactiveCocoa/RACSignal.h#L213-L219

[Maxtws]

Hey, take you time. No job worth to steal your health (except for a male porn star perhaps :) ).
As for TransformPixelMammer I wouldn’t be so sure about wasting it. I would remain both CI and handwritten (CG) versions. I’m already using CI perspective transform and CI perspective correction in my project. The trick is I use CI filter chains only on CIContext initialized with GPU, and sometimes I need the image taken from resources transformed the way I need it for onscreen animation (read CG). My images are not that small to forget about CPU to GPU memory movements. So I would keep both versions.

On Apr 15, 2016, at 3:42 PM, Håvard Fossli notifications@github.com wrote:

Thank you! It may take some time to recover.

Anyways if you are eager to do this and want even better result we could throw our handwritten resampler (AGKTransformPixelMapper) out the window and replace it with CoreImage's own perspective correction api. http://flexmonkey.blogspot.no/2016/04/a-look-at-perspective-transform.html http://flexmonkey.blogspot.no/2016/04/a-look-at-perspective-transform.html Would be awesome and would probably make it both faster and with a lot higher quality! A lot of people would benefit from this.

Remember many people rely on the API so it is wise to mark public methods deprecated. That way we don't need to create a 2.x version of this framework. I like this way of deprecating https://github.com/ReactiveCocoa/ReactiveCocoa/blob/v2.5/ReactiveCocoa/RACSignal.h#L213-L219 https://github.com/ReactiveCocoa/ReactiveCocoa/blob/v2.5/ReactiveCocoa/RACSignal.h#L213-L219
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #37 (comment)

[hfossli]

😂

Hm. Interesting.
The quality is kind of jarring though. Nearest neighbor algorithm isn't as nice as other algorithms.

[Maxtws]

Well, yeah. But any anti-aliasing would kill the performance. Probably Accelerate framework will help or some ideas from OpenCV methods.
Anyway I’m all in it at the moment so feel free to ask any question. My current perspective and task is to define an algorithm for automatic cylinder or (Shepard) distortion correction like scanned book page with would work for like 100ms.

On Apr 15, 2016, at 4:03 PM, Håvard Fossli notifications@github.com wrote:

😂

Hm. Interesting.
The quality is kind of jarring though. Nearest neighbor algorithm isn't as nice as other algorithms.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #37 (comment)