Jump to content

Croppig by fixed ratio is inexact


henko

Recommended Posts

I'm sorry if this has already been covered. I tried to search for it but couldn't find it. (As a side note, having a low "flood control" limit for searches might somewhat counteract people searching for existing topics rather than creating new ones. ;-) )

Anyway, If I create a rectangular selection using the "fixed ratio" option, say 4x1, make a selection and then crop, I end up with an image which is not 4x1 but somewhere close. Rather than 400x100 for example, it would be 399 by 101. I understand that rounding can cause trouble, but if I have a 800x600 image, make a full width selection and crop, I get 799 by 201. I guess 799 means I missed a pixel in my selection, but than the height should at least not be higher than 200.

Link to comment
Share on other sites

  • 4 weeks later...
  • 2 weeks later...

This is fixed in the v3.5.7 update.

Something similar seems to be taking place in the resize tool. A 3888x2600 source image (jpeg 100%) is used.

In test 1, I cropped to an area larger than 1200x900 (fixed 6x4.5 crop) and resized (200dpi, fixed ratio, 6"x4.5". A 1200x900 image resulted as expected

In test 2, I cropped to an area smaller than 1200x900 (same fixed crop) and resized again with the same settings. A 1200x901 image resulted.

Source and test images are available upon request.

Link to comment
Share on other sites

I don't need sample images, the size should be sufficient. Please just provide very explicit step-by-step instructions to reproduce the problem.

1. Open or create a new file (while writing this, i'm using 4000 by 3000px)

2. Selection Rectangle tool, Fixed ratio (width 6, height 4.5)

3. Select an area and crop to selection

4. Image->Resize (Best Quality, absolute size, maintain aspect ratio; resolution: 200 pixels/inch; print size: width 6 inches)

If the selection is larger than 1200x900 pixels, the result is scaled down properly to 1200x900 (in this example)

If the selection is smaller, the result will be 1200x901. Scaling up results in a rounding error somewhere.

The resize action doesn't need to be completed to see the effect. In the resize window, the values for height are filled in. 901 pixels, 4.51 for print size.

Edited by thewarden00
Link to comment
Share on other sites

Those are just rounding errors. Images can only be an integral number of pixels, and each step along the way must be rounded to an integer. Across multiple operations, the rounding errors can pile up and get magnified. There's no way to keep context spread across multiple operations for paint.net to be able to go, "Oh he was doing a 6x4.5 crop, and now he's doing a Resize, and 1200/901 is actually slightly more than 6/4.5 but 1200/900 is perfect, so I'll use that instead." At least, there's no way to do this in a generalized way that makes things more predictable for the user, and without a significant increase in development time and frustration. As far as Paint.NET knows, you really do want a 1200x901 resize, and if it were to second guess the math it was doing then it'd make for an inconsistent experience. "Why does it do 1200x900 sometimes, but other times with the exact same input to Image->Resize, it does 1200x901?" It's kind of a darned-if-you-do, darned-if-you-don't situation.

If you want to ensure you get a 1200x900 resize, then you'll just have to notice that the image is 1200x901 and take appropriate steps. Either change it to a 900 or crop off the last pixel, e.g. with Image->Canvas Size.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

  • 3 weeks later...

Those are just rounding errors. Images can only be an integral number of pixels, and each step along the way must be rounded to an integer. Across multiple operations, the rounding errors can pile up and get magnified. There's no way to keep context spread across multiple operations for paint.net to be able to go, "Oh he was doing a 6x4.5 crop, and now he's doing a Resize, and 1200/901 is actually slightly more than 6/4.5 but 1200/900 is perfect, so I'll use that instead." At least, there's no way to do this in a generalized way that makes things more predictable for the user, and without a significant increase in development time and frustration. As far as Paint.NET knows, you really do want a 1200x901 resize, and if it were to second guess the math it was doing then it'd make for an inconsistent experience. "Why does it do 1200x900 sometimes, but other times with the exact same input to Image->Resize, it does 1200x901?" It's kind of a darned-if-you-do, darned-if-you-don't situation.

If you want to ensure you get a 1200x900 resize, then you'll just have to notice that the image is 1200x901 and take appropriate steps. Either change it to a 900 or crop off the last pixel, e.g. with Image->Canvas Size.

Makes good sense to me, and just un-ticking maintain aspect works. One thought I had was a potential 'forced aspect' selection mode where only selections that exactly match the given ratio are offered.

Your explanation set off a rube goldberg machine in my head, too. Far beyond the scope of a bugfix. But I thought I'd share it.

The undo data contains a list of previous commands, doesn't it? If so, most of the information needed to make context-sensitive decisions is already there. But for most users, having a command do something different (if only slightly) based on when and where an action happens would be very frustrating. So what if there were a way, in some deeply buried menu, for advanced users to overload existing commands or define their own code. And a way to configure the heuristics as well.

In my example: Command 1- fixed crop, Command 2-resize

If these two commands are run in succession, run Magical-Handwavy-Function to check and force dimensions to 1200x900

No need to reply if I'm off my rocker. I need sleep!

Link to comment
Share on other sites

... for advanced users ...

The problem is that all 13 year olds think they are advanced users, which is not the case, and it will still cause hidden variables in many troubleshooting discussions.

"I can't get X to work properly."

"Well try Z."

"Nope"

......... 3000 years of troubleshooting discussion later .........

"Oh you enabled the advanced option #37 didn't you? That totally changes how feature Q works, but only on Tuesdays and Saturdays. Today is Friday, so it's no wonder it doesn't work like it did on Tuesday."

"OH! I'll just set my clock forward. Thanks!"

... 15 minutes later ...

"Now I can't access my bank's website." ... because SSL and digital certificates rely on both client and server agreeing on what time it is or something

:)

I don't think there will ever be an "advanced mode" in Paint.NET. If a feature is so complex that it needs to be buried behind a checkbox, then there probably aren't many people who need it anyway. And anyone who does need it won't be able to find it, or they won't realize that some paragraph explanation is talking about the niche scenario they will encounter in precisely 34 days (nor will they remember it in 34 days time). Thus, I'll have wasted all sorts of time on something that nobody will actually use.

... and a way to configure the heuristics as well.

Well, good luck figuring out a good UI for that one.

Sometimes it's really just fine to be consistent, even with mathematical errors or loss of precision, and let the user take advantage of Undo and then trying again with a slightly different approach.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

  • 1 year later...

This is fixed in the v3.5.7 update.

As far as I can tell, it is still broken rather badly in v3.5.10.

I've got a 16MP camera, with bitmap images on the order of 3456x4608 pixels, and when I try to work with e.g. "2x3" fixed ratio rectangles, by "sweeping out" with the rectangle tool, I'm getting "Bounding rectangle size" with numbers like 1993x3000 and 2000x3011, rather than 2000x3000.

It seems to be an artifact of "CTRL-MINUS-ing" the picture down smaller before applying the rectangle tool: If I "CTRL-PLUS" out to the point where I can see the actual pixels, then I can get the "Bounding rectangle size" ratio to be perfect.

Which, in turn, suggests* to me that the rectangle tool is thinking of its rectangle as living within the "CTRL-MINUSed" small version of the picture, as displayed on-screen, rather than as living within the true full-size bitmap image [which exists somewhere out there in software never-never land].

Anyway, if you stick with a rectangle tool which considers things from the point of view of the small picture displayed on-screen, then it would be really nice if you could add an algorithm to bump the final corner point [in the true, large picture] over to the closest nearby point which provides a perfect ratio [or a closest approximation of the perfect ratio], where, in the case of a tie, maybe the algorithm could choose the point which makes [or one of the points which make] for the largest rectangle [within the true, large picture].

Thanks.

*Either that, or else you're using something akin to 16-bit floats to compute the ratio...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...