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.
So, you are saying that, in the context of a 1000 pixel cropped image, one or two pixels difference would be noticeable?
That’s only 0.1% and, without doubt, invisible to anyone with normal vision.
In any case, when cutting the matt board for a frame, either the aperture in the board will cover the edge of the printed area or the cut itself could be off by more than 0.1%
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.
I’ve had this happening often, few pixel off one side. Quit often, resizing to 1200px long length, with the other should be 800px but I get 799 or 798px.
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.
Hi folks,
only for my salvation I’ve made the same test George does.
First with 14% view setting a 1:1 crop and I can resize the frame by 7 pixels height and width identically
I must correct myself.
When initializing the crop tool it mentions “4256x2832 3/2”.
When selecting 3/2 from the drop-down list it mentions “4248x2832 3/2”. Exactly 3/2.
Playing with the sides or the corners doesn’t change that ratio in pixels in both cases.
I had not considered the zoom factor, as I generally always have it “to fit” when cropping. Unless I was cropping particularly small I don’t think I’d ever think to change that.
But still… while zoom may affect what sizes are achievable, all such sizes should adhere to the selected ratio. E.g. if zoomed to 50%, it would be reasonable that only odd or only even sizes would be achievable. But there is no reason for 1/1 ≠ 2600/2601
But this is the key to why you are getting these anomalies. Whilst moving a control point with the mouse, the pixel position is calculated in screen coordinates, which are the translated to relative image positions, which could well include fractional differences.
Considering the zoom factor only impacts the precision of the pixel accuracy.
Testing with 10% zoom i can only reach 10 pixel steps, but always an exact 1:1 ratio with the identical pixel size for height an width.
I am working on 27" with 1920 x 1080 resolution
It is actually the opposite of this. When I drag the lower bound, I am adjusting a Y position and this will indeed be in fractional (or multiple) pixels at times. But I am not touching the X positions. When I drag the Y to a place on the screen, PL is giving me a rounded answer in whole pixels. Then it should take that rounded answer and simply X=Y. You may be right in that the rounding is occurring only for display and in fact my Y value is 2600.4 and the X position of the frame is such that it is on a half pixel which causes it to round UP to 2601. But this is the nub of the whole problem.
In the end, PL must come up with a whole pixel solution, and it should honour the ratio with whole pixels where possible. For a 1:1 ratio, this is always possible. Zoom levels, display scaling, mouse accuracy, et al are only responsible for which values of the dragged axis are possible to reach. The non-dragged axis is derived from a calculation where 1=1 and pixels have nothing to do with it. In a non 1:1 ratio, yes, some rounding may have to occur. For example in a 3:2 ratio if the height is not a multiple of 2 then the width will have a half pixel to deal with. But if the height is a multiple of 2, then there is always a perfect 3:2 answer and PL does not always deliver.
Here’s an example of exactly this, which only took me a few seconds to recreate by dragging only the bottom border of the crop frame. I made PL say 800 for the height. There is no other correct answer for the width than 1200, yet there you see 1201. To reiterate, I never touched the width.
Oh! And interestingly, while trying to prove the point that corner dragging does not suffer this problem… I discovered it does!! I carefully dragged the lower right corner expecting never to be able to reproduce the 1201x800 but in fact I just did.
This leads me to believe the problem is that the rounding is occurring only for display, and the real frame size is fractional. I suspect it is only fixed to integer values when applied, but even then the ratio is not respected. It should be respected at all times during the drag, even if it has to work in fractional values under the covers.
I’ve made the same test George does.
