Width x Height displays incorrect values

DEVONthink Feedback
1

The column “Width x Height” reports values scaled to 72 dpi. This seems like a mistake since I would interpret the numbers it outputs like 1920x1080 as having units of “pixels”. However, I have a document which has a dpi set to 175 and so DT reports the image as being smaller. The document in pixels is 1400 x 875 (perfect for a desktop picture on my laptop), but the DT column reports 576 x 360.

To check your maths and my theory… 875 * (72 / 175) = 360

That means that the column “Width x Height” reports size in a unit scaled by “dots per pixel” which I would normally think should be always equal 1 since a “pixel” is thought to be the atomic scale of a digital image (i.e. not divisible).

Even stranger is that Height in a Smart Group options for “Height is 875” and I get my file in question but still with the bad column value.

It’d be nice to get these values as separate columns too.

Might as well also ask at this moment for an “aspect ratio” column. I have an AppleScript that computes it rather fast and stores it to the comments, but this seems like a bad idea long in the long term because I’ll either erase important information or generate duplicate values if I were to append to the front/back of the comment field. I would settle for user-defined “formula columns” much like one might generate via an SQL query.

2

This issue reported in 2010 is still outstanding.

The values for the number of pixels in a jpg reported in the “Width x Height” column are incorrect, except for the special case of the jpg being flagged as 72 dpi. As the OP points out, this is because DT scales the values it reports as if the jpg was flagged at 72 dpi. So a jpeg with 3000x3000 pixels that happens to contain a flag saying 300 dpi is reported as having 480x480 pixels in the “Width x Height” column. But clearly, an image that has 3000x3000 pixels has that number of pixels no matter what the dpi flag in the jpeg happens to say. The dpi is irrelevant for reporting the number of pixels and should be ignored by DT in the W x H column.

3

Thanks for the heads up, the next maintenance release will fix this.