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

standardize on u32 vs i32 for jpeg coordinates/width etc to support large JPEGs #126

Merged
merged 3 commits into from
Dec 4, 2024

Conversation

mcroomp
Copy link
Collaborator

@mcroomp mcroomp commented Dec 2, 2024

We were using i32s which overflow for very large JPEGs which can be 65535x65535.

In general this cleans up the code quite a bit.

@mcroomp mcroomp requested a review from Melirius December 2, 2024 11:34
Comment on lines +480 to +487
self.mcuv = NonZeroU32::new(
(1.0 * self.img_height as f64 / (8.0 * self.sfhm as f64)).ceil() as u32,
)
.ok_or_else(|| LeptonError::new(ExitCode::UnsupportedJpeg, "mcuv is zero"))?;

self.mcuh =
NonZeroU32::new((1.0 * self.img_width as f64 / (8.0 * self.sfvm as f64)).ceil() as u32)
.ok_or_else(|| LeptonError::new(ExitCode::UnsupportedJpeg, "mcuh is zero"))?;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why not make use of integer arithmetics? And I have an impression that these checks are superfluous: checks of nonzero img_height and img_width are enough.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah I guess that's just a round up

@mcroomp mcroomp merged commit e4f6244 into main Dec 4, 2024
3 of 4 checks passed
@mcroomp mcroomp deleted the u32 branch December 4, 2024 14:05
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.

2 participants