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

Allowing disabling of pixel limit #316

Merged
merged 1 commit into from
Apr 4, 2016
Merged

Allowing disabling of pixel limit #316

merged 1 commit into from
Apr 4, 2016

Conversation

kentongray
Copy link
Contributor

As discussed in #250 allowing boolean values for limitInputPixels this partially removes the limit. Unfortunately there are other limits based upon the int32 for width/height that I stumbled on shortly after so I'd like to take a stab at that but this gets you significantly larger images. Let me know your thoughts

@lovell
Copy link
Owner

lovell commented Nov 30, 2015

Hello, thanks for adding this feature. I'll add comments inline.

Are you able to update the API docs to mention the acceptance of a boolean value?

I'm happy for any always-positive parameters to change from signed to unsigned integer if that helps too.

@@ -805,6 +805,19 @@ describe('Input/output', function() {
});
});

it('Disabling limit works', function(done) {
sharp(fixtures.inputJpg).metadata(function(err, metadata) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the use of metadata required here?

@kentongray
Copy link
Contributor Author

@lovell should be able to handle the noted things and docs, would you be opposed to adding a really large image to the test suite to test these things better?

@lovell
Copy link
Owner

lovell commented Nov 30, 2015

"would you be opposed to adding a really large image to the test suite"

Great idea. As long as the compressed file size is not "really large", this would also provide a good example of libvip's low memory usage.

A single-colour, non-interlaced PNG (with row filtering disabled?) should compress the best. Decompression memory usage relates to image width rather than height, so perhaps try something like 2000px wide and whatever-you-need px high.

@OneIron1
Copy link

lovell:

I have a use case where an analyst needs the ability to specify an area of an image that needs further "review"... in this case, the images are what I would consider "massive", 2-3Gb tiffs that i convert to JPGs, normally in the range of 40k-50k pixels wide/tall. What intrigues me about your sharp library, besides the performance metrics, is the ability to read once...crop multiple times unlike GM or others where it is necessary to re-read the image each time an action is required. Simple "tiling" doesn't work here because I need to apply proprietary "filters" to the image where edge sampling is important. Obviously these images are larger that the existing 268million pix limit. Is this limit a 'NIX system limitation?

@kentongray
Copy link
Contributor Author

just an update my holidays were a little hectic but I do plan on getting back to wrapping this up in January

@OneIron1
Copy link

OneIron1 commented Jan 5, 2016

Great to hear... Hope you had at least a little down to time to unwind/relax/recoup?!

Regards,

Scott

Sent from my iPhone

On Jan 4, 2016, at 6:04 PM, kentongray notifications@github.com wrote:

just an update my holidays were a little hectic but I do plan on getting back to wrapping this up in January


Reply to this email directly or view it on GitHub.

@lovell
Copy link
Owner

lovell commented Jan 6, 2016

@kentongray No worries, thanks for the update. Let me know if you need any guidance.

@lovell
Copy link
Owner

lovell commented Feb 4, 2016

The master branch is now using the vips8 C++ bindings so you'll notice a conflict or two when rebasing.

@webbrandon
Copy link

This would be a great feature. Is anyone currently working on @lovell comments?

How is the current permitted value calculated for limitInputPixels?

I get a exception telling me the permitted range but assume it varies depending on the machine because I noticed others using higher values than I (current: 268402689). Is this correct?

@lovell
Copy link
Owner

lovell commented Mar 30, 2016

@webbrandon Please go ahead and work on this if you're willing and able. limitInputPixels is currently set here to the maximum value allowed for WebP, which is the lowest common denominator when it comes to limits in supported formats.

@kentongray
Copy link
Contributor Author

Hey guys sorry for dropping off the planet on this one, but nothing will make progress like needed a feature (can't wait to use the padding). OK so I made the following changes.

  1. Update docs
  2. Added a large single color image (cyan ftw) at 20,000x14,000 (above the default limit) and crushed it so it is 43k.
  3. Updated tests to use the large image with true and false values

The only problem I potentially see is the large image test takes a bit (16267ms) on my machine. Not sure if that is acceptable or not.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.01%) to 98.832% when pulling 3c3b3da on iOffice:master into b2d7d4c on lovell:master.

@kentongray
Copy link
Contributor Author

i'm guessing the failing test is due to the large image... let me know your thoughts on how to proceed blarg really was trying to wrap this up today

@lovell
Copy link
Owner

lovell commented Apr 3, 2016

Loving the cyan, thanks for the updates @kentongray.

It looks like the new test is timing out on Windows CI. Are you able to double the test-win limit to 60000ms?

Please can you squash to a single commit (I've recently enabled PR squashing as the default behaviour but this PR was created before that, so you'll have to do it manually). More importantly, please add your good self as a fully-fledged contributor.

@kentongray kentongray force-pushed the master branch 3 times, most recently from 0695fe1 to ed5b393 Compare April 4, 2016 03:19
@coveralls
Copy link

Coverage Status

Coverage increased (+0.01%) to 98.832% when pulling 3e88428 on iOffice:master into b2d7d4c on lovell:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.01%) to 98.832% when pulling ed5b393 on iOffice:master into b2d7d4c on lovell:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.01%) to 98.832% when pulling ed5b393 on iOffice:master into b2d7d4c on lovell:master.

Update docs
Added a giant image for testing
Adding myself to contributors
Added tests to verify giant image can be opened
Extend test-win time limit (because of large images)
@coveralls
Copy link

Coverage Status

Coverage increased (+0.01%) to 98.832% when pulling 8241884 on iOffice:master into b2d7d4c on lovell:master.

@kentongray
Copy link
Contributor Author

unfortunately still failed it seems 😭

@lovell lovell merged commit 8c9c070 into lovell:master Apr 4, 2016
@lovell
Copy link
Owner

lovell commented Apr 4, 2016

No worries, I'll look after the failing test (either add more time or skip on Windows).

Thanks again Kenton for all your work on this feature - this will be included in v0.14.1.

@lovell lovell added this to the v0.14.1 milestone Apr 4, 2016
@lovell
Copy link
Owner

lovell commented Apr 4, 2016

@kentongray your test is now <50s on Windows CI with 71fb839

@kentongray
Copy link
Contributor Author

yay thanks @lovell

@webbrandon
Copy link

no problem @kentongray . thank you very much for your contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants