Kann man High DPI simulieren?

[theo]

DPI sind Pixel pro Zoll.

Nein, DPI sind dots per Inch (Punkte pro Zoll).
PPI sind pixels per inch (Pixel pro Zoll).
Soweit mir bekannt ist, nimmt man DPI für den Drucker (Druckpunkte) und PPI für den Bildschirm (Pixel).
Deshalb die Frage.
Aber ja, inhaltlich ist es nicht so wichtig.

[Mathias]

Hier ist es schön beschrieben:
https://99designs.de/blog/design-tipps/ppi-vs-dpi/
Anscheinend gibt es einen Unterschied, ob Monitor oder Printer.

[theo]

Hier ist es schön beschrieben:
https://99designs.de/blog/design-tipps/ppi-vs-dpi/
Anscheinend gibt es einen Unterschied, ob Monitor oder Printer.

Ganz genau. Deshalb wundere ich mich, dass es hier Hi-DPI heisst.
Hat ja mit Drucken nichts zu tun.

[wp_xyz]

Kannst du noch kurz erklären, wie der Zusammenhang zwischen PPI (Ist DPI nicht eigentlich für den Druck?) und Bildgrösse ist?

Wenn du eine TImageList auf das Formular setzst, wird eine Größe in Width und Height angegeben, normalerweise 16. Durch einen Doppelklick auf der ImageList kannst du mit Hilfe von "Neue Größe/Auflösung" weitere Bildgrößen definieren, z.B. 24, 32. Insgesamt stellt die ImageList dann in diesem Beispiel Bilder in drei Größen zur Verfüging: 16x16, 24x24, 32x32. Normalerweise gibst du diese drei Bilder unter "Mehrere Größen hinzufügen" ein - im Ordner images/general-purpose der Lazarus-Installation hat Ally für all diese Fälle Bilder gemalt. Fehlt eine Größe, wird das fehlende Bild aus dem größten der Reihe herunterskaliert, was erstaunlich gut funktioniert.

Warum das alles? Wenn die Eigenschaft Scaled auf true gesetzt ist, wertet die ImageList die aktuelle Bildschirmauflösung aus und verwendet die Bilder, die am besten zur aktuellen Auflösung passen. Also wenn dein System unter 144ppi läuft (150%) läuft, wird im obigen Beispiel das 24er-Bild verwendet, denn 150% von 16 (das Bild bei 100%) ist 24.

Es gibt noch eine weitere Rafinesse. Das Control, das die ImageList verwendet, hat eine Property ImagesWidth, normalerweise 0. Das bedeutet: "Nimm für 96ppi die Bildgröße, die als Width und Height der ImageList direkt definiert ist". Mit Hilfe von ImagesWidth kann man aber eine andere Basisgröße definieren. Auf diese Weise kann ein und dieselbe Imageliste für Controls verwendet werden, die unterschiedliche Bildgrößen verlangen. Eine ListView, z.B. hat zwei ImageLists, eine SmallImages und eine LargeImages mit 16x16 bzw. 32x32 Pixeln normalerweise. Steht nun bei LargeImagesWidth der Wert 32, so fordert die Listview bei 96ppi das 32er-Bild von der ImageList an; dasselbe Bild kann aber auch von der SmallImages-Liste für 16x16 verwendet werden (SmallImagesWidth wäre dann 16, oder 0, weil Imagelist.Width schon 16 ist). In diesem Fall müssen natürlich noch mehr Bildgrößen unter "Neue Größe/Auflösung" definiert werden: 16, 24, 32 und 32 (ok - das haben wir schon) 48, 64. All diese Größen gibt es in der Lazarus-Icon-Collection im Ordner "images/general-purpose".

[wp_xyz]

Nein, DPI sind dots per Inch (Punkte pro Zoll).
PPI sind pixels per inch (Pixel pro Zoll).
Soweit mir bekannt ist, nimmt man DPI für den Drucker (Druckpunkte) und PPI für den Bildschirm (Pixel).

Richtig, ist halt eine schlampige Ausdrucksweise. Wobei man natürlich auch die Frage stellen kann, was konzeptionell der Unterschied zwischen einem "Dot" und einem "Pixel" ist.

[theo]

@wp_xyz: Danke für die Informationen!

Richtig, ist halt eine schlampige Ausdrucksweise. Wobei man natürlich auch die Frage stellen kann, was konzeptionell der Unterschied zwischen einem "Dot" und einem "Pixel" ist.

Ja, habe oben auch angemerkt, dass es inhaltlich keinen Unterschied macht.
Trotzdem wäre PPI der passendere Begriff, wenn man es schon unterscheiden will.

[Ally]

Hallo theo,

Also dein kleinstes Bild ist 20x20px. Könnte es auch 16x16px sein?
Wie entscheidet Lazarus, welche Grösse bei welchen DPI genommen wird?

wp_xyz hat das ja schon ausgezeichnet erklärt.

Er hat auch geschrieben:

Fehlt eine Größe, wird das fehlende Bild aus dem größten der Reihe herunterskaliert, was erstaunlich gut funktioniert.

Meiner Erfahrung nach wird hier nicht skaliert.
Lazarus selbst verwendet nur drei Größen 100%, 150% und 200%. Auf einem Monitor mit 125% wird dann das 100er und auf einem mit 175% das 150er benutzt, halt immer was noch passt.

@wp_xyz

Es gibt noch eine weitere Rafinesse. Das Control, das die ImageList verwendet, hat eine Property ImagesWidth

Danke für den Tip, das war mir noch gar nicht bewusst.

Gruß Roland

[wp_xyz]

Fehlt eine Größe, wird das fehlende Bild aus dem größten der Reihe herunterskaliert, was erstaunlich gut funktioniert.

Meiner Erfahrung nach wird hier nicht skaliert.
Lazarus selbst verwendet nur drei Größen 100%, 150% und 200%. Auf einem Monitor mit 125% wird dann das 100er und auf einem mit 175% das 150er benutzt, halt immer was noch passt.

Doch, die fehlenden Bilder werden skaliert: Nimm eine ImageList, definiere eine zusätzliche Auflösung 64 (zusätzlich zur Basisgröße 16) und füge zur ImageList nur ein 64er-Bild von den General-Purpose-Icons hinzu. Es erscheint im ImageList-Editor das 64er-Bild, aber eben auch ein 16er-Bild, das nur aus dem 64er erzeugt worden sein kann.

Wahrscheinlich meinst du aber das Skalieren, wenn die geforderte Bildgröße nicht in der Serie der vordefinierten Größen enthalten ist, also in deinem Beispiel, wenn der Monitor 125% hat, in der ImageListe aber nur die Größen für 100%, 150% und 200% vorhanden sind. Dann verwendet das LCLScaling tatsächlich nur das nächst-kleinere Bild. Eigentlich seltsam, denn genauso wie die fehlende Größe in der Designphase erzeugt werden könnte, müsste jetzt auch vom größten oder vom nächstgrößeren Bild heruntergerechnet werden können. Vielleicht hatte Ondrej Bedenken wegen der Laufzeit?

[Ally]

Hallo wp_xyz,

Wahrscheinlich meinst du aber das Skalieren, wenn die geforderte Bildgröße nicht in der Serie der vordefinierten Größen enthalten ist, also in deinem Beispiel, wenn der Monitor 125% hat, in der ImageListe aber nur die Größen für 100%, 150% und 200% vorhanden sind. Dann verwendet das LCLScaling tatsächlich nur das nächst-kleinere Bild.

Ja, genau. Aufgefallen ist mir das auf meinem "125% Laptop". Dort Verwendet Lazarus für die Menüicons die 16er und skaliert nicht vom 24er auf 20x20 herunter.
Unter dem Strich ist das wahrscheinlich auch gut so. Bei vielen Icons würde das herunterskalieren zu unschönen Ergebnissen führen. Und das die Icons bei 125% und 175% etwas kleiner sind fällt kaum auf.
Wenn man es gerne etwas feiner abgestuft hätte, ist das ja auch kein Problem. Einfach noch die zwei Icongrößen dazupacken und man hat über den gesamten Auflösungsbereich, praktisch immer die passende Icongröße.

Gruß Roland

[theo]

Unter dem Strich ist das wahrscheinlich auch gut so. Bei vielen Icons würde das herunterskalieren zu unschönen Ergebnissen führen.

Resampling wenn keine passende Grösse da ist, wäre mMn schon die beste Lösung.
Das sieht OK aus, wenn das Verfahren stimmt.
Mit Gimp etc. macht man es ja auch nicht anders, wenn man vom grösseren Bild kleinere erzeugt.
Man könnte dann auch nur einfach das grösste angedachte Bild mitgeben.
Performance bedenken hätte ich nicht direkt bei 40x40px und Netzwerk-Traffic fällt auch nicht an.
Die "Exe" wäre sogar kleiner, falls das jemanden interessiert.
Natürlich nur als "Fallback". Wer für viele Icons optimieren möchte, sollte das derzeitige Modell anwenden können.

[BeniBela]

Man kann auch nur die Schriftgröße ändern

In GTK legt man eine Datei gtkrc an

Code: Alles auswählen

include "/usr/share/themes/Breeze/gtk-2.0/gtkrc"
style "user-font"
{
    font_name="Noto Sans Regular 24"
}
widget_class "*" style "user-font"
gtk-font-name="Noto Sans Regular 24"
gtk-theme-name="Breeze"
gtk-icon-theme-name="breeze"
gtk-fallback-icon-theme="gnome"
gtk-toolbar-style=GTK_TOOLBAR_ICONS
gtk-menu-images=1
gtk-button-images=1

und startet es mit:

GTK2_RC_FILES=~/gtkrc program

[Ally]

Hallo theo,

noch kurz zu deiner Frage:

Ganz genau. Deshalb wundere ich mich, dass es hier Hi-DPI heißt.

Das hängt mit der normativen Kraft des Faktischen zusammen.
Du kannst ja mal nach einem HiPPI - Monitor suchen. Die meisten Monitorhersteller sprechen von "HiDPI" oder "High DPI".

Zu den Wirrungen bei den Begrifflichkeiten, meine ganz persönlich Meinung:
Angaben wie, das Bild hat eine Auflösung von 72 PPI, sind natürlich erst einmal völlig wertlos. Ein Bild hat keine PPI, schon alleine deshalb nicht, weil es keine Inches hat.
Ein nicht ganz ernst gemeintes Beispiel: Meine Kamera liefert Bilder die 6000x4000 Pixel groß sind. Wie groß müsste meine Kamera sein, wenn die Bilder 72 PPI haben?
Erst in Verbindung mit den Werten eines Ausgabegeräts kann man berechnen wie groß ein Bild darauf ausgegeben wird.
Auch zwischen Grafikern und Druckern werden die Bezeichnungen wohl häufig munter durcheinander gewürfelt, was tatsächlich ja auch keinerlei Auswirkungen hat.

Gruß Roland

[wp_xyz]

Fehlt eine Größe, wird das fehlende Bild aus dem größten der Reihe herunterskaliert, was erstaunlich gut funktioniert.

Meiner Erfahrung nach wird hier nicht skaliert.
Lazarus selbst verwendet nur drei Größen 100%, 150% und 200%. Auf einem Monitor mit 125% wird dann das 100er und auf einem mit 175% das 150er benutzt, halt immer was noch passt.

Doch, die fehlenden Bilder werden skaliert: Nimm eine ImageList, definiere eine zusätzliche Auflösung 64 (zusätzlich zur Basisgröße 16) und füge zur ImageList nur ein 64er-Bild von den General-Purpose-Icons hinzu. Es erscheint im ImageList-Editor das 64er-Bild, aber eben auch ein 16er-Bild, das nur aus dem 64er erzeugt worden sein kann.

Wahrscheinlich meinst du aber das Skalieren, wenn die geforderte Bildgröße nicht in der Serie der vordefinierten Größen enthalten ist, also in deinem Beispiel, wenn der Monitor 125% hat, in der ImageListe aber nur die Größen für 100%, 150% und 200% vorhanden sind. Dann verwendet das LCLScaling tatsächlich nur das nächst-kleinere Bild. Eigentlich seltsam, denn genauso wie die fehlende Größe in der Designphase erzeugt werden könnte, müsste jetzt auch vom größten oder vom nächstgrößeren Bild heruntergerechnet werden können. Vielleicht hatte Ondrej Bedenken wegen der Laufzeit?

Wie Ondrej mir mitteilte, habe ich hier ein wichtiges Detail schlichtweg vergessen. Es gibt noch das Ereignis TImagelist.OnGetWidthForPPI. Hier kann man angeben, wie groß ein Bild bei einer beliebigen Pixel-Dichte werden soll. Im folgenden Beispiel skaliert die Bildgröße genau proportional zu den PPI:

Code: Alles auswählen

procedure TForm1.ImageList1GetWidthForPPI(Sender: TCustomImageList;
  AImageWidth, APPI: Integer; var AResultWidth: Integer);
begin
  AResultWidth := AImageWidth * APPI div 96;
end;

Die Zwischengröße wird dabei durch Interpolation aus dem nächst-größeren gespeicherten Bild erzeugt.