vips_resize for resizing #977

jardakotesovec · 2017-10-05T09:49:48Z

This is follow-up for #954.

Bit struggle with failing tests. So intentionally posted tests adjustments in second commit so its easy to go back and forward to double check these adjustments.

I got

  1) Embed PNG with alpha channel:
     Error: Expected maximum similarity distance: 5. Actual: 12.
      at test/fixtures/index.js:157:27
      at test/fixtures/index.js:33:9

If you compare new expected image with original - I think it could be considered as improvement, or at least not worse result. It might have something to do with that vips_resize combine somewhat differently shrink and reduce. So in this case I just updated the expected result.

  2) Partial image extraction Extract then rotate:
     Error: Expected maximum similarity distance: 5. Actual: 8.
      at test/fixtures/index.js:157:27
      at test/fixtures/index.js:33:9

Here it gets confusing for me, because test is comparing jpeg with png which already makes difference and not sure what the intention if it has something to do with alpha handle testing. I could not tell any difference visually and by comparing jpeg with jpeg I got good similarity. But not sure if its good fix.

  3) Gamma correction alpha transparency:
     Error: Expected maximum similarity distance: 20. Actual: 23.
      at test/fixtures/index.js:157:27
      at test/fixtures/index.js:33:9

Similar situation as in 2) as its comparing png with jpeg and expected result is already in pretty poor quality. I tried png and jpeg outputs with and without this PR and could not tell difference apart from some slightly different jpeg compression.

I am happy to make any adjustments based on your feedback, but also feel free to make the adjustments yourself.. I am ok either way :-).

I would make the PR for 'lessShrinkOnLoad' thing once this is sorted out.

Thanks!

lovell

This is looking great, thank you Jarda. I've added a couple of questions/comments inline.

lovell · 2017-10-05T19:02:08Z

src/pipeline.cc

-        yshrink = std::max(1, static_cast<int>(floor(yfactor)));
-        xresidual = static_cast<double>(xshrink) / xfactor;
-        yresidual = static_cast<double>(yshrink) / yfactor;
-        if (


I'm slightly worried that removing the swap here will break something but the tests that were added for the original bug #387 continue to pass. There's probably an edge case that, if ever found, we can add the fix and another test for later :)

Thats removed because xresidual is not used after that point. Its used only before for the shrink_on_load edge case.

lovell · 2017-10-05T19:03:29Z

src/pipeline.cc

@@ -279,23 +279,6 @@ class PipelineWorker : public Nan::AsyncWorker {
        }
        xfactor = static_cast<double>(shrunkOnLoadWidth) / static_cast<double>(targetResizeWidth);
        yfactor = static_cast<double>(shrunkOnLoadHeight) / static_cast<double>(targetResizeHeight);
-        xshrink = std::max(1, static_cast<int>(floor(xfactor)));


Can we remove the xshrink, yshrink, xresidual and yresidual variables entirely now?

Thats what I wanted to do. But they are still used outside of the resize logic for the shrink_on_load logic.
Particularly xresidual and yresidual is used here

sharp/src/pipeline.cc

Line 245 in a3457a0

if (shrink_on_load > 1 && (xresidual == 1.0 || yresidual == 1.0)) {

this reduce the shrink_on_load.

and xshrink is also used in context of shrink_on_load here

sharp/src/pipeline.cc

Line 226 in a3457a0

xshrink == yshrink && xshrink >= 2 &&

lovell · 2017-10-05T19:04:15Z

test/unit/extract.js

@@ -98,6 +98,7 @@ describe('Partial image extraction', function () {
    sharp(fixtures.inputPngWithGreyAlpha)
      .extract({ left: 20, top: 10, width: 380, height: 280 })
      .rotate(90)
+      .jpeg()


Good catch, this is a much better test now.

lovell · 2017-10-05T19:05:04Z

test/unit/gamma.js

      .toBuffer(function (err, data, info) {
        if (err) throw err;
-        assert.strictEqual('png', info.format);
+        assert.strictEqual('jpeg', info.format);
        assert.strictEqual(320, info.width);
        fixtures.assertSimilar(fixtures.expected('gamma-alpha.jpg'), data, { threshold: 20 }, done);


I wonder if we can remove the { threshold: 20 } bit now that you've updated this to (correctly) use JPEG output?

Will try it out tomorrow.

lovell · 2017-10-05T19:07:50Z

Oh, I had an idea for the shrink-on-load optional name too: fastShrinkOnLoad, defaulting to the current true behaviour.

jardakotesovec · 2017-10-05T19:29:34Z

Sounds good. And if its fastShrinkOnLoad: false it would just use that lower shrink_on_load factor that I stole from vipsthumbnail, right? That should be easy.. just creating test will be tricky :-).

lovell · 2017-10-05T19:48:49Z

"if its fastShrinkOnLoad: false it would just use that lower shrink_on_load factor that I stole from vipsthumbnail, right?"

Yes, that's correct, thank you.

In terms of testing variable shrink-on-load, you could try extracting a 9x8 "problem" region that you know will be different based on the fastShrinkOnLoad setting. This will prevent the assertSimilar() test helper from further scaling before calculating a hash value.

jardakotesovec · 2017-10-06T09:26:17Z

@lovell So here is update. I removed successfully the treshold for 3) Gamma correction alpha transparency:.

And added the fastShrinkOnLoad logic so you can review that in one go.

lovell · 2017-10-06T17:15:56Z

Thanks for the updates Jarda. As predicted that one test failure is annoying. Perhaps resize to just under half (or quarter) the original size and extract({ top: 0, left: 0, width: 9, height: 8 }) a 9x8 region in the same pipeline rather than use resize alone?

jardakotesovec · 2017-10-06T18:19:02Z

@lovell Interesting.. Will double check that later on.. it was not failing on my computer.. maybe some oversight..

jardakotesovec · 2017-10-09T08:24:16Z

@lovell It's really passing locally. Only difference I could think of is somewhat different vips version. Locally I compiled from vips-8.6.0-4 package (OS X).

If I change expect to the other file (fastShrinkOnLoad: false vs fastShrinkOnLoad: true) similarity goes from 0 to 14, which seems that it can recognize the difference between desired and undesired result good enough.

Using extract I don't think it would be make much of the difference, because the issue I am capturing is around 1px offset, which is always around 1px regardless if I resize and extract or just resize.

Any idea why we are getting different result on travis?

lovell · 2017-10-09T10:56:17Z

Are you using libjpeg or libjpeg-turbo? The shrink-on-load feature of libjpeg-turbo is SIMD-enabled and has slightly different rounding logic. The Linux and Windows builds both use the libjpeg-turbo version.

If so, perhaps just increase the threshold to 7 and add a separate test that verifies the result of fastShrinkOnLoad: true is not similar to the result of fastShrinkOnLoad: false?

lovell · 2017-10-09T11:02:05Z

A rebase is probably required too. My fault, sorry. I had to rebase the suit branch against master to pick up recently merged PRs.

jardakotesovec · 2017-10-09T12:14:17Z

@lovell On my system I have only libjpeg. And your libvips build you are providing for sharp -
are these built also just with libjpeg on OS X? If so, I should update the test as you suggested, otherwise it would make more sense to update the expect image.

jardakotesovec · 2017-10-09T12:18:28Z

I should also do my 'image shifting' test with jpeg-turbo to see how bad it gets there.

jardakotesovec · 2017-10-09T12:30:00Z

@lovell Just recompiled vips with jpeg-turbo and you are right, thats really that makes the difference. So maybe compiling with turbo on os x would also make sense for consistent result for these nuanced situations :-).

Will double check how much difference it makes to my shifting issue.

jardakotesovec · 2017-10-09T12:53:56Z

@lovell ok.. so shifting is very much the same. There were just subtle differences for some pixels shades. Let me know if in this context makes more sense to you make the test happy with both jpeg libraries (with higher treshold) or just update expected image with turbo

lovell · 2017-10-09T17:30:47Z

We should probably support both libjpeg variants for the tests if it's as simple as increasing the threshold a little bit :)

The prebuilt libvips provided for OS X is based on the homebrew default, currently libjpeg. We should probably switch to the turbo version as that will make at least a 2x difference for Mac users - leave that bit with me.

jardakotesovec · 2017-10-10T08:14:52Z

@lovell ok.. updated, anything else?

coveralls · 2017-10-10T08:24:15Z

Coverage increased (+0.003%) to 99.024% when pulling d3f9780 on jardakotesovec:vips_resize into 80b7b60 on lovell:suit.

lovell · 2017-10-10T18:05:00Z

Podivuhodný, děkuji!

jardakotesovec mentioned this pull request Oct 5, 2017

WIP Using vips_resize and less aggressive shrink_on_load #954

Closed

lovell reviewed Oct 5, 2017

View reviewed changes

Repository owner deleted a comment from coveralls Oct 5, 2017

jardakotesovec force-pushed the vips_resize branch from cb9c598 to f642da9 Compare October 6, 2017 09:22

lovell force-pushed the suit branch from 87d066e to 9e7ff19 Compare October 8, 2017 09:04

Use vips_resize instead of custom logic

cdccfe4

jardakotesovec force-pushed the vips_resize branch from f642da9 to 9e2677d Compare October 10, 2017 08:13

Add fastShrinkOnLoad option

d3f9780

jardakotesovec force-pushed the vips_resize branch from 9e2677d to d3f9780 Compare October 10, 2017 08:18

Repository owner deleted a comment from coveralls Oct 10, 2017

lovell merged commit 18870a1 into lovell:suit Oct 10, 2017

lovell mentioned this pull request Oct 10, 2017

Expose shrink on load in resize #956

Closed

lovell added a commit that referenced this pull request Oct 10, 2017

Doc refresh, changelog and dead code removal for #977

331e5a6

lovell added a commit that referenced this pull request Oct 10, 2017

Doc refresh, changelog and dead code removal for #977

300b0d5

lovell pushed a commit that referenced this pull request Oct 19, 2017

Switch to libvips' resize, make fastShrinkOnLoad optional (#977)

d0f66c3

lovell added a commit that referenced this pull request Oct 19, 2017

Doc refresh, changelog and dead code removal for #977

3c88c84

lovell mentioned this pull request Nov 20, 2017

Error: shrink: parameter hshrink not set #1030

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

vips_resize for resizing #977

vips_resize for resizing #977

jardakotesovec commented Oct 5, 2017

lovell left a comment

lovell Oct 5, 2017

jardakotesovec Oct 5, 2017

lovell Oct 5, 2017

jardakotesovec Oct 5, 2017

lovell Oct 5, 2017

lovell Oct 5, 2017

jardakotesovec Oct 5, 2017

lovell commented Oct 5, 2017

jardakotesovec commented Oct 5, 2017

lovell commented Oct 5, 2017

jardakotesovec commented Oct 6, 2017

lovell commented Oct 6, 2017

jardakotesovec commented Oct 6, 2017

jardakotesovec commented Oct 9, 2017

lovell commented Oct 9, 2017

lovell commented Oct 9, 2017

jardakotesovec commented Oct 9, 2017

jardakotesovec commented Oct 9, 2017

jardakotesovec commented Oct 9, 2017 •

edited

Loading

jardakotesovec commented Oct 9, 2017 •

edited

Loading

lovell commented Oct 9, 2017

jardakotesovec commented Oct 10, 2017

coveralls commented Oct 10, 2017 •

edited

Loading

lovell commented Oct 10, 2017

vips_resize for resizing #977

vips_resize for resizing #977

Conversation

jardakotesovec commented Oct 5, 2017

lovell left a comment

Choose a reason for hiding this comment

lovell Oct 5, 2017

Choose a reason for hiding this comment

jardakotesovec Oct 5, 2017

Choose a reason for hiding this comment

lovell Oct 5, 2017

Choose a reason for hiding this comment

jardakotesovec Oct 5, 2017

Choose a reason for hiding this comment

lovell Oct 5, 2017

Choose a reason for hiding this comment

lovell Oct 5, 2017

Choose a reason for hiding this comment

jardakotesovec Oct 5, 2017

Choose a reason for hiding this comment

lovell commented Oct 5, 2017

jardakotesovec commented Oct 5, 2017

lovell commented Oct 5, 2017

jardakotesovec commented Oct 6, 2017

lovell commented Oct 6, 2017

jardakotesovec commented Oct 6, 2017

jardakotesovec commented Oct 9, 2017

lovell commented Oct 9, 2017

lovell commented Oct 9, 2017

jardakotesovec commented Oct 9, 2017

jardakotesovec commented Oct 9, 2017

jardakotesovec commented Oct 9, 2017 • edited Loading

jardakotesovec commented Oct 9, 2017 • edited Loading

lovell commented Oct 9, 2017

jardakotesovec commented Oct 10, 2017

coveralls commented Oct 10, 2017 • edited Loading

lovell commented Oct 10, 2017

jardakotesovec commented Oct 9, 2017 •

edited

Loading

jardakotesovec commented Oct 9, 2017 •

edited

Loading

coveralls commented Oct 10, 2017 •

edited

Loading