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

Update limits to be byte based #115

Merged
merged 1 commit into from
May 4, 2019
Merged

Conversation

birktj
Copy link
Member

@birktj birktj commented Apr 23, 2019

Limiting allocated bytes is more effective and useful than image
size. Especially when incrementally decoding an image which may not
fit in memory, limiting pixels doesn't make much sense. Also see the discussion in image-rs/image-tiff#29

This will change the public api in that the Limits struct now has a different field.

This fixes #105

@HeroicKatora @fintelia @Shnatsel what do you guys think?

self.processed = vec![0; self.line_size(width)]
let bytes = self.limits.bytes;
if bytes < self.line_size(width) {
// FIXME: DecodingError::Other is used for backwards compatibility.
Copy link
Member

@HeroicKatora HeroicKatora Apr 23, 2019

Choose a reason for hiding this comment

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

This reasoning doesn't make much sense, as this is a backwards incompatible commit–a public member of Limits was renamed from pixels to bytes.

Copy link
Member Author

Choose a reason for hiding this comment

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

I simply copied code from the previous limit stuff, but yeah I realize that this doesn't really make sense. I will add a new error variant.

Copy link
Contributor

@Shnatsel Shnatsel left a comment

Choose a reason for hiding this comment

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

Looks good to me, except for one nit.

pub struct Limits {
/// max number of pixels: `width * height` (default: 67M = 2<sup>26</sup>)
pub pixels: u64,
/// maximum number of bytes the decoder is allowed to allocate, default is 64M
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be helpful to clarify that this is Mib, not Mb. See https://en.wikipedia.org/wiki/Mebibyte

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, I always wondered which was which

Copy link
Member

Choose a reason for hiding this comment

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

There's also 'the decoder will allocate less than 10K bytes' somewhere below, as 10*1024.

@Shnatsel
Copy link
Contributor

Overall I think this is definitely a step in the right direction.

CI failure on nightly seems to be a rustc bug, could anyone familiar with the CI setup comment on that?

@HeroicKatora
Copy link
Member

@Shnatsel That's just #113, a side effect of having the tests ran in all configurations in Travis.

Limiting allocated bytes is more effective and useful than image
size. Especially when incrementaly decoding an image which may not
fit in memory, limiting pixels dosen't make much sense.
@birktj
Copy link
Member Author

birktj commented May 4, 2019

Since nobody else has commented this I will merge it.

@birktj birktj merged commit d81f117 into image-rs:master May 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Limit buffer size instead of image dimensions
3 participants