In the other thread it was the fixed frame size, here it’s the ratio.
I couldn’t reproduce it. A ratio of 1:1 will start with the shortest site of the image. No calculation involved, no roundings. I presume.
The exact dimensions mentioned in the other thread are the goal not the method. I have the same goal. In both cases this is done by dragging and in both cases we noted that the ratio is not respected when there is no need for rounding. In the other thread’s case, 1500 x 1000 should be intrinsic to the 3:2 ratio, but it was giving 1500x999 or 1500x1001. It is understandable if the width is set to 1501 that the other dimension cannot be 1000.6 and so will round, logically, to 1001. But 1500x1000 is an exact multiple of the 3:2 ratio — no rounding required.
In my case, a 1:1 ratio is a common denominator for any size and so there is never a need to round pixels. To reiterate, if I drag a corner it is always exactly 1:1. It is only if I drag a side that the error occurs.
Yes it matters because my intent is a square shot, and while for some use cases a pixel or two may not matter, in others it will.
For instance, when I export I do so at full size, whereafter an automated script uses ImageMagick to add watermarks and resize the image to fixed dimensions. Sometimes I want to crop as closely as I can, so I set the crop to my goal dimensions, which the ImageMagick tool will address by not needlessly scaling the image. If it’s off by a couple of pixels, then I am going to get a scaled image that will introduce distortion as it is forced back to the intended ratio. Sure, 2 pixels in a few thousand won’t be noticeable, but there’s no need for it to be anything other than exact.
The workaround (at least for 1:1, I haven’t tested 3:2) is to finish with a corner drag to properly square up the figures. But often it is more convenient (and why else would PL offer the option?) to drag a side so that the other dimension stays centred on its current size.
In short, it does not always honour the ratio when the crop size (should be) a whole multiple of that ratio. That’s a bug, and my history tells me it’s a rounding bug. Possibly not enough precision in the calculation of the “other” dimension.
I’ve a D750. Non edited the size is 6016x4016. It’s a common 2x3 sensor. When you calculate it, it should be 6016x4011 rounded. When I use the crop tool the initial value is 6016x4016: the image size. Now you can make the further calculations. Going to 1500 on the longest site (1500/6016)*4016=1001 rounded.
The D700, also a 2x3 sensor measures 3872x2592. Also not 2x3 exactly. I mention the image pixels. The amount of sensor pixels is I think 2 more per site.
From a mathematical perspective I think we don’t need to argue. 2925x2923 is not equal to 1:1. Why would this not be a bug?
I understand the whole topic may not be worth the discussion for some of you because you don’t care. But if you don’t care about the topic, then why do you spend your valuable time on it? What is the downside of fixing this bug? I can’t think of any.
Why don’t we all invest our energy in improvement rather than finding excuses to keep bugs unaddressed?
Cropping is capturing a specific content from within the original picture. That’s the main and for me the only purpose to use a crop tool. If I want a specific size I do that afterwards.
But I’m interested how things work. So I don’t understand why you don’t get a square with even sites. I do get them, exactly the same. If you don’t get that equal result then there must be a reason.
Yes. It’s noticeable as soon as I see two numbers that are not equal when they should be. My point is not that it will always be noticeable in the output, but that in my workflow it can cause processing to be performed which a true 1:1 crop would avoid. Extra processing brings with it the possibility of image degradation and even if I didn’t process it beyond PL, I wouldn’t have a square image and I can certainly imagine a web upload function that demanded a square and got snippy when it wasn’t.
But regardless of whether you or I can see a difference in any given case…
I couldn’t have put it better myself.
Also, if 0.1% is not enough for concern, I managed to get it up to 0.38%. I have a piece of software on my Mac that accepts icons of 512 pixels in size and it will reject an image that is not perfectly square.
And finally, I think this is proof it’s a rounding problem. I struggled to get the error at the above dimensions, but as you drag larger you can see the numbers change further and further out of step. So I went big and managed to get a 3 pixel error.
Judging from your screen capture you have not done the one thing I described as the cause of the bug — drag a side of the crop rectangle. It looks like you’ve just gone into the crop tool and selected 1:1 and done no dragging (as it is showing full frame height). And to clarify again, it will not always be wrong, but as you drag it, for some of the time the numbers will not agree.
I have dragged the horizontal side, the vertical side and the corner, the numbers stay equal. So I can’t reproduce your problem. I tried different images from different camera’s. None of them gave problems, even sides all the time.
Sorry, I stand corrected. Maybe it is another Mac vs Windows thing? This happens all the time on my images. The one I did the above testing on is 4928x3264 and without any prior processing (other than default) I went straight to the crop tool, set 1:1, and started dragging. It doesn’t take many goes to see the problem over about 400 pixels. It gets commonly out by 1 over about 1000 pixels, and out by 2 around 2000 pixels.
Furthermore you can see the error even more easily while slowly dragging, as at very small dimensions the two numbers roll over in lock step. As you get to larger dimensions you can see them changing at different times, even if they ultimately land on a correct result. Describing this it occurs to me it may be to do with Mac Retina displays, where one screen pixel is not equal to one logical pixel (at the OS level). I think the Windows equivalent is display scaling (which in my experience at work is not terribly well executed even by Microsoft).
When I say it happens “all the time” I don’t use square crops on everything, but every time I do I notice this and have to drag a corner as the final action. I note that in my current project there are already 8 square crops so that will be why I noticed it enough to start this thread.
With the example of Zkarj, 4928x3264, you might get 1200x795.
I think PL and maybe every editor, starts with the 100% frame and calls it by it’s nominal size being 2x3. But the sensor size isn’t exactly 2x3, and the image sizes will be 2x2 pixels less when I’m right. And the other ratio’s are derived from these setting.
Leaves the 1x1 ratio as a different example.
I don’t see how the original frame has any bearing on the crop ratio unless “original” is selected. In that case, sure, the original ratio may be off from a perfect 3:2 or 4:3, but when I select 3:2 explicitly (or indeed 1:1) the mathematics should not involve the original frame size except as an upper bound.
Also, if it was the original ratio informing the error, then it would not be possible to get an exact 3:2 or 1:1 crop at some sizes, but you can always achieve an exact ratio (rounded to whole pixels) simply by dragging a corner handle. For example, my square crops I target a final size of 2600x2600. If I drag by a side, I might get 2600x2601, but by dragging a corner out and back a little I can reliably get 2600x2600.