Image size, DPI (was Re: Gorm is broken)

[Eric Wasylishen]

Hi Riccardo,

On 2011-05-03, at 10:01 AM, Riccardo Mottola wrote:

> Hi,
> 
> fixing the images is incorrect I think. 96DPI and 72DPI are both "acceptable" 
> values for screen displays. There is actually no real standard and screens 
> have a varying resolution. Thus 72 and 96 DPIs are just custom values.
> Traditionally, Mac saved images with no "explicit" resolution as 72dpi and 
> windows tends to use 96dpi.
> 
Yes. However, the value 72 dpi is important in GNUstep/Cocoa because 1 point in 
the window's base coordinate system = 1 pixel, and a point is 1/72 inch. (even 
though it's an arbitrary number in some sense because no modern desktop screens 
are really as low resolution as 72 PDI).

So drawing an image with 1 pixel = 1 pixel means treating the image as if it is 
72 DPI, which is what the code did before my patch, i.e. it set the dimensions 
in points to the dimensions in pixels.

I just checked on Cocoa and it ignores the dpi of PNG's and assumes them to be 
72dpi, however it reads and uses the dpi of TIFF's exactly as GNUstep does now. 
In addition, Cocoa supports multi-image TIFF's, something I would like to add 
support for to GNUstep. This means we can provide high-res versions of the 
default artwork which are only used when a scale factor > 1 is set.

> I think your patch is wrong in concept: no developer would expect their 
> button or any other gui element to be resized according to the display 
> resolution. A pixel is a pixel in that case.

By default a pixel is a pixel. But when you set GSScaleFactor to a number other 
than 1, everything is scaled. 

Using the DPI metadata means a slight inconvenience for people who don't use 
the scale factor feature (ensuring all images are set to 72dpi), but it allows 
providing high-resolution versions of images for when higher scale factors are 
used, so I think it makes sense.

Eric

> Riccardo
> 
> Gregory Casamento wrote:
>> Hey Eric,
>> 
>> I saw the commit changing things to 72DPI.  It does seem to correct the 
>> issue.  I believe we'll have to do with same for some of the apps in GAP as 
>> well since the DPI settings there are wrong as well for a few of them. :)
>> 
>> GC
>> 
>> On May 1, 2011, at 7:00 PM, Eric Wasylishen wrote:
>> 
>>> Hi Gregory,
>>> I just noticed the scaled down icons as well. It should be fixed now.
>>> 
>>> With r32920 and r32916 I read the DPI metadata in TIFF's and PNG's, and use 
>>> it to calculate the dimensions of images in points. Some of the included 
>>> GNUstep images had their DPI metadata set to 96, which is why they were 
>>> being scaled down, so I set these to 72.
>>> 
>>> btw, some images are getting slightly blurred, at least with the cairo 
>>> backend (the scroller arrows, the "home" button in file dialogs.) I'm not 
>>> sure why that is, but it's likely one of my recent image changes, and I'll 
>>> look into it.
>>> 
>>> --Eric
>>> 
>>> On 2011-05-01, at 4:06 PM, Gregory Casamento wrote:
>>> 
>>>> I'm seeing the icons scaled down on some apps.   Could this be because
>>>> of this change as well?
>>>> 
>>>> On Sun, May 1, 2011 at 1:40 PM, Germán Arias <address@hidden 
>>>> <mailto:address@hidden>> wrote:
>>>>> OK, the problem was that I don't recompile the palette "Boxes". Now
>>>>> works, thanks.
>>>>> 
>>>>> 
>>>>> On sáb, 2011-04-30 at 23:35 -0600, Eric Wasylishen wrote:
>>>>>> Assuming you are running trunk of everything, see if undoing my change r 
>>>>>> 32895 makes the problem go away. The command to do that is "svn merge 
>>>>>> --change -32895 Source/NSImage.m" from the gui directory. In that 
>>>>>> revision I removed some code in -compositeToPoint: which cached the 
>>>>>> image.
>>>>>> 
>>>>>> I'm running trunk of base/gui/back and gorm and they seems to work for 
>>>>>> me.
>>>>>> 
>>>>>> Cheers,
>>>>>> Eric
>>> 
> 
>