| |
| |
|
| - Seite 1 - |
|
Manfred
Barei | Hallo,
bitte einmal Testen, bei mir kommt immer ein falscher Wert.
KompilierenMarkierenSeparierenDeclare Bild&
windowtitle "Farbtiefe"
cls
usefont "MS Sans Serif",16,0,0,0,0
setdialogfont 1
Bild& = @Create("hPic",-1,"Test.bmp") das Bild hat 16 Farben = 8-Bit
DrawPic Bild&,0,0;0
DeleteObject Bild&
Locate 10, 1
print "Farbtiefe : " + @Str$(%BmpB) + "-Bit" angezeigt werden 32-Bit
waitinput
end
Gruß
Manfred |
|
| |
| Zu wenig Wissen ist gefärlich, zu viel auch.(XProfan X4) | Win 10 Pro 64 | Win7 Ultimate 32/64 | AMD FX-8320, 16GB, GeForce GT 630 | | 08.08.2008 ▲ |
|
| |
|
|
| |
| |
| - Seite 1 - |
|
Frank
Abbing | | Nein, habs ebenfalls festgestellt... |
|
| |
| |
| |
|
|
 | Habs doch oben bereits erwähnt, die Werte beziehen sich auf das hPic.
Werte nach LoadBmp mal getestet?
Ich glaube Roland hatte so etwas erwähnt wie das die Farbtiefe der hPics sich nach der eingestellten Desktopfarbtiefe orientiert. Ich kann mir vorstellen das create("hPic" ein hPic erzeugt, und darauf das Bild läd. Das geladene Bild wird dabei ja auf die hPic-Farbtiefe konvertiert, nach Laden hat es dann die "korrekt-angezeigten" Werte, auch wenn die Datei anderen Inhalt trägt. 
Eine Include welche aus verschiedenen Bildtypen Eigenschaften wiedergibt wäre hier hilfreich - oder Du spielst mit GDI herum. |
|
| |
| |
| |
|
|
RGH | iF hat (ausnahmsweise ;) ) recht: Hier wird die Farbtiefe des hPic& bestimmt u8nd die ist immer exakt die Farbtiefe des Desktop, entsprechend auch die Farbanzahl. Und die allermeisten Rechner sind auf eine Farbtiefe von 32 Bit eingestellt, wobei 24 Bit für die Farben verwandt werden. (Farbanzahl ist also 2^24)
Gruß
Roland |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 08.08.2008 ▲ |
|
| |
|
|
Jörg
Sellmeyer |
Werte nach LoadBmp mal getestet?
Das gibt es ja nun mal nicht mehr (seit XPRofan10?). Da es ja %BitsPixel gibt, ist die ja eigentlich für die ermittlung der Bildschirmfarbtiefe zuständig.
Die Farbtiefe (Bits/Pixel) des zuletzt mit DrawPic, DrawSizedPic, CopyPic, CopySizedPic, create("hPic",...), create("hSizedPic",...) oder create("hPicCopy",...) geladenen Bildes.
Wenn ich mir das so durchlese, sehe ich da aber keinen Hinweis darauf, daß sichder Wert auf die Farbtiefe des Desktops bezieht. |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 08.08.2008 ▲ |
|
| |
|
| |
| |
| - Seite 2 - |
|
|
RGH | Hallo,
das LoadBmp gibt es natürlich noch, nur heißt es jetzt auch DrawPic:
KompilierenMarkierenSeparieren
Und hier wird die Farbtiefe der Bmp-Datei angegeben In diesem Fall also 4 Bit.
Bei "DrawPic &hPic, ..." wird natürlich die Farbtiefe des mit DrawPic auf den Bildschirm gebrachten Bildes, also von &hPic angegeben. Und diese ist nun mal die Farbtiefe des Desktops.
Ich sollte in der Hilfe etwas ausführlicher auf diese Feinheiten eingehen. Der aus der alten Hilfe kopierte Begriff "geladen" ist hier irreführend, da er im üblichen Sprachgebrauch nur zutrifft, wenn das zu zeichnende Bild direkt aus einer Datei geladen wird, und nicht wenn es aus einer Speicherbitmap geholt wird.
Gruß
Roland |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 08.08.2008 ▲ |
|
| |
|
|
Jörg
Sellmeyer | Ich finde, Du solltest lieber %bmpp so anpassen, daß es die korrekte Farbtiefe widergibt.  |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 08.08.2008 ▲ |
|
| |
|
|
RGH | Jörg Sellmeyer
Ich finde, Du solltest lieber %bmpp so anpassen, daß es die korrekte Farbtiefe widergibt.
Tut es ja, und zwar im obigen Beispiel die von &hPic. Der Befehl DrawPic setzt die Farbtiefe auf den Wert der Bitmap, die er zeichnet. Er kann gar nicht mehr wissen, welche Farbtiefe irgendein Bild hatte, das irgendwann mal mit einem anderen Befehl geladen wurde.
Gruß
Roland |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 08.08.2008 ▲ |
|
| |
|
|
Frank
Abbing | RGH
Jörg SellmeyerIch finde, Du solltest lieber %bmpp so anpassen, daß es die korrekte Farbtiefe widergibt. Tut es ja, und zwar im obigen Beispiel die von &hPic. Der Befehl DrawPic setzt die Farbtiefe auf den Wert der Bitmap, die er zeichnet. Er kann gar nicht mehr wissen, welche Farbtiefe irgendein Bild hatte, das irgendwann mal mit einem anderen Befehl geladen wurde. Gruß Roland
Das ist aber unlogisch. Immerhin sagt die Hilfe: Die Farbtiefe (Bits/Pixel) des zuletzt mit DrawPic, DrawSizedPic, CopyPic, CopySizedPic, create("hPic",...), create("hSizedPic",...) oder create("hPicCopy",...) geladenen Bildes. DrawPic wird jedoch hier gar nicht zum Laden verwendet, sondern zum Kopieren und dürfte deswegen in dem Fall nicht die Variable verändern. |
|
| |
| |
| |
|
|
| Hehe, das kann man wieder sehen wie mal will, (fast) wie beim explode-Problem.
Letztendlich wäre es wohl XProfan (oder auch "smart" lol) wenn Roland hier eben eine Ausnahme deklariert damit der erwartete Wert zurückgeliefert wird, einfach deshalb, weil er imho per GDI sowieso die Werte einmalig besitzt und es damit keinen Sinn macht, extra eine Include aufzusetzen, nur weil die Werte (eigentlich) "überschrieben" gehören. Schliesslich kann man die Tiefe des hPics mit %bitsPixel ermitteln. |
|
| |
| |
| |
|
|
Jörg
Sellmeyer | Wenn der Wert nur die Farbtiefe des Bildschirms zurückgibt, ist er schlicht überflüssig, da es ja, wie gesagt, bereits %BitsPixel gibt. Von einer Variablen, die sich (laut Hilfe) auf geladene Bitmaps bezieht, erwarte ich, daß sie auch einen Wert zurückliefert, der sich auf das Bild bezieht.
Und ich halte es wirklich für sinnvoller, den Rückgabewert anzupassen, als die Hilfe mit einem überflüssigem Wert zu "korrigieren". |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 08.08.2008 ▲ |
|
| |
|
|
RGH | Frank Abbing
Immerhin sagt die Hilfe: Die Farbtiefe (Bits/Pixel) des zuletzt mit DrawPic, DrawSizedPic, CopyPic, CopySizedPic, create("hPic",...), create("hSizedPic",...) oder create("hPicCopy",...) geladenen Bildes. DrawPic wird jedoch hier gar nicht zum Laden verwendet, sondern zum Kopieren und dürfte deswegen in dem Fall nicht die Variable verändern.
Hier differiert das, was die Hilfe sagt nun mal von dem, was ich gemeint und programmiert habe. Sicherlich kann man nun drüber streiten, was die bessere Lösung ist. Mein Gedanke war, dass es schwer nachvollziehbar ist, warum DrawPic bei einer Syntaxvariante diese vier Systemvariablen setzt und bei einer anderen nicht. Daher entschied ich mich, sie immer zu setzen. Beim Erweitern der Hilfe habe ich aber etwas zu leichtfertig die alte Formulierung übernommen, die sich auf den alten Befehl LoadBMP bezog.
Wie dem auch sei: Jetzt sollte zumindest klar sein, wie und wann XProfan diese Systemvariablen setzt.
Gruß
Roland |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 08.08.2008 ▲ |
|
| |
|
|
Frank
Abbing | Nachtrag:
&BmpCol
--------------------------------------------------------------------------------
Version: 3.3 / 11.0
Farbanzahl des zuletzt mit DrawPic, DrawSizedPic, CopyPic, CopySizedPic, create("hPic",...), create("hSizedPic",...) oder create("hPicCopy",...) geladenen Bildes.
Konnte das Bild nicht geladen werden, wird &BmpCol auf 0 zurückgesetzt.
Oftmals ist die Anzahl der Bits/Pixel interessanter als die Farbanzahl. Diese kann mit %BmpC ermittelt werden.
.
Du sprichst hier in der Hilfe von %BmpC... |
|
| |
| |
| |
|
(1.320)
Deutsch
English
Français
Español
Italia