Android 1.5 unterstützt 24bit Displays!

[iRaS]

ich muss das nochmal ausgraben, sorry.

bin zwar nicht der linux freak, aber eben doch informatiker. die behauptungen in diesem thread beruhen eigentlich alle auf der aussage, dass der framebuffer0 16 bit farbtiefe hat. jetzt ist framebuffer seit linux leider zweideutig.

es gibt den framebuffer auf der grafikkarte in dem das bild gespeichert ist das zum anzeigegerät geschickt wird und es gibt in linux etwas das sich framebuffer nennt, aber rein gar nichts mit der ausgabe zu tun hat.

so hat ein standard linux system zwar immer einen framebuffer (ich weiß nicht wieviel bpp der fb im kernel hat) und dann gibt es noch den x-server der dann die grafiktreiber verwendet und bis zu 32bit farbtiefe unterstüzt.

frag doch mal jemand diesen android freak wie man denn auslesen kann welche farbtiefe verwendet wird, das würde dann vllt. klarheit über die sache bringen. denn wie sich das hier liest ist sich niemand sicher. und auch in dem thread mit dem hintergrundbild das nur 16bit farbtiefe hat: ist schon sehr richtig was hier geschrieben wurde: das kann rein aus performance gründen gemacht werden, dass das bild, das ständig aus dem speicher geladen werden muss, nur in 16bit gespeichert wird.

die diskussion mit dem app sollte ich wohl gänzlich ignorieren - ich arbeite für eine firma die software vertreibt: ihr würdet nicht glauben womit einige entwickler ihr geld verdienen. da würde es mich nicht im geringsten wundern wenn die 8 bit gifs verwenden.

Viele Grüße
Thomas

shit! so viele tabs offen... das war im falschen topic und im anderen topic gings doch noch weiter... hmm wär ein mod so freundlich den beitrag dem richtigen thread zu zuordnen?
https://www.android-hilfe.de/forum/...atsaechlich-nur-16-bpp-65536.5305-page-4.html

 

[Gdroid]

so weit ich weiß zeichnet die App die Farben mit einem Code und es wird nicht einfach nur ein GIF Bild vorgehalten :/

Tja, wäre schön wenn einer der sich auskennt bzg. Android bzw. von Samsung mal klartext redet!

 

[fexpop]

frag doch mal jemand diesen android freak wie man denn auslesen kann welche farbtiefe verwendet wird, das würde dann vllt. klarheit über die sache bringen.

Android schaut genau da nach, wo ich auch geschaut habe! Auch wird direkt in eben das genannte Framebuffer Device geschrieben. Steht auch im Android Porting Guide (unter "Display Drivers", habe ich in diesem oder dem Schwesterthread schon mal verlinkt).

Im Übrigen gibt auch das GL System während des Bootens eine Farbtiefe von 16bpp aus.

die diskussion mit dem app sollte ich wohl gänzlich ignorieren - ich arbeite für eine firma die software vertreibt: ihr würdet nicht glauben womit einige entwickler ihr geld verdienen. da würde es mich nicht im geringsten wundern wenn die 8 bit gifs verwenden.

Schau in den Quellcode des "Galaxy Lie Detector". Es gibt kein Hintergrundbild. Das Bild wird mit Android-Mitteln als Bitmap von der App erzeugt, undzwar einmal mit 24bpp und einmal mit 16bpp (RGB_565).

Grüße, Felix

 

[iRaS]

@fexpop: ich meinte die anwendung im schwesternthread. dieses tune wiki oder wie das heißt...

Android schaut genau da nach, wo ich auch geschaut habe!

quelle?

die aussage mit der größe des framebuffers hat da schon mehr hand und fuß, da in dem textfile alles mögliche drin stehn könnte - wer weiß ob es verwendet wird und ob es nicht irgendwo eine zweite textdatei gibt in der 24 oder 32 steht? das guide habe ich auch überflogen, da steht aber auch nicht wo man für sein programm die durchaus wichtige information bekommt ob das gerät nun mit 16 oder 24/32 bit betrieben wird.

öffnet man nun ein 32bit png mit farbverläufen sieht man allerdings deutlich das dithering. ist zwar kein beweis, aber genau darauf kommt es ja an (dass die medien und programme in 32bit ausgeben können.

dennoch kann ich mir nicht vorstellen, dass das von samsung verbaute amoled keine 24 bit darstellen kann. es bleibt also die frage ob samsung mit der aussage gelogen hat (sie sagen ja nur dass das display das kann, oder werben sie auch damit dass man seine medien in 32 bit genießen kann?). schließlich haben sie in anderen geräten auch schon amoleds verbaut. wo ist also die einschränkung auf 16 bit zu finden wenn das display tatsächlich 24 bit darstellen kann? irgendjemand hat ja geschrieben das dass display 24 bit unterstüzt (laut aussage eines o2 oder samsung mitarbeiters - was natürlich fraglich bleibt)... vllt. ist die einschränkung ja auch der zu kleine framebuffer des grafikchips?

 

[fexpop]

quelle?

Wenn dir die Ausführungen im Porting Guide nicht genügen, kannst du gerne die Android Quellen durchforsten. Hab ich auch schon hinter mir.

Mit Rootrechten kannst du es auch mit FBIOGET_FSCREENINFO und FBIOGET_VSCREENINFO ioctl Aufrufen machen. Das ist das, was Android tatsächlich macht.

Meines Wissens basieren aber die Angaben in /sys/devices/virtual/graphics/fb0/bits_per_pixel eben auf diesen ioctl Aufrufen, bits_per_pixel ist ja keine festgeschriebene Textdatei.

Zusammenfassend sind Zweifel daran, dass das Galaxy derzeit tatsächlich nur 16bpp darstellt, nicht begründet!

Ein kleiner Hinweis: Meinen "Galaxy Lie Detector" hatte ich eigentlich unter anderem Namen programmiert, um zu zeigen, dass das Galaxy eben doch 24bpp unterstützt. Macht es aber nicht!

Desweiteren halte ich als juristischer Laie es für einem Verbraucher nicht zumutbar, zwischen Fähigkeiten des verbauten Displaypanels und denen des Gesamtgerätes zu unterscheiden.

Sollte o2 keine Einsehen haben, und meinen Vertragsrücktritt akzeptieren, werde ich das gerne mit Hilfe des Verbraucherschutzes oder eines Anwaltes klären lassen.

 

[iRaS]

ich nochmal:

in einem thread der auch verlinkt wurde ging es darum mit bildern zu testen ob es 16 bit oder 24 bit darstellt. dass es im hintergrund nicht dargestellt wird ist bekannt. und tatsächlichen machen es die meisten programme auch nicht. aber mir ist gerade etwas aufgefallen. im anhang ist ein bild. öffnet das mal mit verschiedenen programmen.

ich habe es einmal mit astro image viewer geöffnet - ich hab die zoom funktion nicht gefunden oder es gibt keine, einmal mit der app picture viewer - da sind klar die 16 bit farbabstufungen im 24 bit teil des bildes zu sehen, aber dann habe ich es auch mit dem standard programm (bei mir steht da bild anzeigen) geöffnet und voila: die abstufungen sind nicht zu sehen. auch bei genauem hinsehen nicht. ich sehe auch kein dithering wie ich es vermuten würde, aber vllt. bin ich auch zu blind. interessant wäre es ein screenshot davon zu machen und das dann zu vergrößern, da bei dem zoom auf dem gerät ja wenn nur das dithering feiner würde.

vielleicht wirft das mal ein anderes licht auf die sache wenn es tatsächlich keine farbabstufungen hat. allerdings muss man beim screenshot schießen wieder vorsichtig sein: maybe macht das screenshot programm ein screenshot von einem framebuffer der tatsächlich nur 16 bit hat anstatt das was tatsächlich zum bildschirm geschickt wird.

ein weiterer interssanter test wäre es ein png24 von drei farbverläufe zu machen in dem alle drei farbverläufe den gleichen ursprung haben aber unterschiedlich bearbeitet wurden. z. B. der oberste bleibt 24 bit, der darunter wird durch dither auf 16 bit runtergeschraubt und der letzte ohne dither auf 16 bit runtergeschraubt... ich hab keinen dither filter für ps aber ich schau mal ob ich das auch so hinkriege...

 

[iRaS]

Meines Wissens basieren aber die Angaben in /sys/devices/virtual/graphics/fb0/bits_per_pixel eben auf diesen ioctl Aufrufen, bits_per_pixel ist ja keine festgeschriebene Textdatei.

wie der pfad ja schon sagt ".../devices/virtual/..." handelt es sich dabei virtuelle devices. ich hab viel zu viel zu tun (und verschwende schon wieder meine zeit wärend ich eig. arbeiten sollte) um mich detailierter mit der funktionsweise der android oberfläche zu beschäftigen. aber irgendwas meine ich mal gehört zu haben, dass android quasi eine virtuelle maschine die javacode ausführt ist (mit einigen zusätzlichen und modifizierten bibliotheken).

möglicherweise ist genau das der springende punkt: man kann für das linux darunter auch c programme schreiben und diese durch die java oberfläche ansprechen. diese könnten dann ohne umwege über java und die virtuellen devices mit dem grafikchip kommunizieren... sind natürlich alles nur annahmen, aber deine aussagen sind auch nur annahmen. ebenso wie dein programm nur ein java programm ist und dann eben nur mit dem virutellen device kommuniziert.

hier noch ein zitat aus der wikipedia:

Weitere wichtige Bausteine sind die auf der von Sun Microsystems entwickelten Java-Technik basierende virtuelle Maschine Dalvik und die dazugehörigen Android-Java-Klassenbibliotheken.

 

[fexpop]

möglicherweise ist genau das der springende punkt: man kann für das linux darunter auch c programme schreiben und diese durch die java oberfläche ansprechen. diese könnten dann ohne umwege über java und die virtuellen devices mit dem grafikchip kommunizieren... sind natürlich alles nur annahmen, aber deine aussagen sind auch nur annahmen. ebenso wie dein programm nur ein java programm ist und dann eben nur mit dem virutellen device kommuniziert.

Du kannst auch einfach(?) ein anderes Betriebssystem auf dem Galaxy installieren, dass dann eben 24bpp unterstützt. Ich gehe jedenfalls davon aus, dass die Hardware das hergeben würde.

Aber innerhalb des auf dem Galaxy installierten Android Betriebssystems geht es eben nicht. (Korrigiert mich, wenn das NDK direkten Hardwarezugriff ermöglicht). Eben deshalb ist mein Programm eben auch ein Java Programm, das so auf die Hardware zugreift, wie es innerhalb des Systems möglich ist.

Ich nehme an, wir schreiben ein wenig aneinander vorbei: Du möchtest glaube ich wissen, ob die Hardware 24bpp darstellen könnte. Daran habe ich keine ernsthaften Zweifel (wenngleich ich Samsung mittlerweile vieles zutraue).

Ich hingegen möchte, dass das Galaxy auch tatsächlich Grafiken mit 24bpp darstellt. Das kann mein Galaxy jedenfalls nicht.

Grüße, Felix

P.S.: Ich glaube, du solltest noch ein wenig über das sysfs lernen. (Ich auch)

 

[solidify]

in einem thread der auch verlinkt wurde ging es darum mit bildern zu testen ob es 16 bit oder 24 bit darstellt. dass es im hintergrund nicht dargestellt wird ist bekannt. und tatsächlichen machen es die meisten programme auch nicht. aber mir ist gerade etwas aufgefallen. im anhang ist ein bild. öffnet das mal mit verschiedenen programmen.

Das Bild und der Thread stammen von mir & ich freue mich über jedes Danke

https://www.android-hilfe.de/forum/...rundbilder-mit-photoshop.5146.html#post-50710

Das seltsame ist doch nach wie vor, dass manche Apps scheinbar 24bit-fähig sind, das Hintergrundbild jedoch - auch nach dem neuesten Update H - ungedithert in 16bit dargestellt wird!

 

[fexpop]

Das seltsame ist doch nach wie vor, dass manche Apps scheinbar 24bit-fähig sind,

Welche Applikation ist 24bit fähig?

 

[fexpop]

im anhang ist ein bild. öffnet das mal mit verschiedenen programmen.
einmal mit der app picture viewer [...] und voila: die abstufungen sind nicht zu sehen.

Ich hab mir das Bild gerade mit dem anerkanntermaßen 16bpp Hero angesehen. Auch das sind die Abstufungen des 24bpp Teils deutlich schwächer, falls überhaupt zu erkennen.

Ich denke, dass der 24bpp Teil des Bild einfach anders "vorgedithered" ist. Daher geht der Lie Detector ja auf Nummer sicher und erzeugt das Bild selbst, mit für jeden Pixel klar definierter Farbe.

Grüße, Felix

 

[solidify]

@fexpop:

entweder 24bit-fähig oder sie dithern extrem gut. Ich kann es nicht unterscheiden . Und zwar wenn Du zum Beispiel die Bilder direkt aus Google Mail heraus öffnest, sieht die Welt gleich ganz anders aus.

 

[Gdroid]

wenn man beim Galaxy die orange hinterlegen Icons, also beim selektieren anschaut, dann sieht dieser Orange-Effekt auch sehr flüssig aus..der ja etwas von außen nach innen gradiert ist..auch das Grün in der Batterieanzeige ist saube nicht?

könnt doch teils mit 24bpp sein..allerdings da wo es am meisten auffält, dem Desktop..ist's 16bpp und noch schlecht gedithert X'D

 

[fexpop]

@fexpop:

entweder 24bit-fähig oder sie dithern extrem gut. Ich kann es nicht unterscheiden .

Ich hab's doch schon geschrieben. Das von iRaS angehängte Bild sieht auf dem HTC Hero genauso aus. Es wird durchweg nur 16bpp Farbtiefe verwendet!

Was wollt ihr denn noch? Die Beweislage ist doch erdrückend

1. Das sysfs gibt für den Frambuffer 16bpp an.
2. Das GL System gibt 16bpp an.
3. Programmatisch erzeugte 24bpp Farbverläufe werden als RGB_565 16bpp Farbverläufe dargestellt ("Lie Detector")
4. Ein gut aussehendes angeblich 24bpp Bild (von iRaS) wird auf dem 16bpp Hero genauso dargestellt wie auf dem Galaxy.

Wie kann man da nur im entferntesten daran glauben, dass manche Apps es *irgendwie* doch schaffen 24bpp darzustellen

Grüße, Felix

 

[iRaS]

@fex: das sind die fakten ja, aber es gibt eben noch nicht bestätige vermutungen, dass es durch nativen code möglich sein könnte direkt auf den framebuffer der grafikkarte zugreifen könnte (ohne virtuelle devices dazwischen).

ich persönlich kann mir gut vorstellen, dass diverse programme (z. B. das standardprogramm für bildanzeige oder der videoplayer) nativen code im hintergrund ausführen zur ausgabe und das javazeugs nur zur steuerung dient. mit gewissheit kann ich sogar sagen, dass die codecs nicht in java programmiert sind.

Android (Betriebssystem) ? Wikipedia

Anwendungen für die Androidplattform werden ausnahmslos in Java geschrieben, jedoch greifen diese in geschwindigkeitskritischen Bereichen auf zahlreiche in C oder C++ geschriebene, native Bibliotheken zu. Darunter befinden sich neben Codecs für die Medienwiedergabe auch ein Webbrowser auf der Basis von WebKit, eine Datenbank (SQLite) und eine auf OpenGL basierende 3D-Grafikbibliothek.

 

[fexpop]

aber es gibt eben noch nicht bestätige vermutungen, dass es durch nativen code möglich sein könnte direkt auf den framebuffer der grafikkarte zugreifen könnte (ohne virtuelle devices dazwischen).

Was stützt diese Vermutungen, die ja außerhalb dieses Forums eh nicht existieren: Nichts! Der einzige Hinweis ist, das in dem von dir geposteten Bild im vorgeblichen 24bpp Teil die Abstufungen nicht so deutlich zu erkennen sind wie im 16bpp Teil. Das ist aber wie jetzt schon mehrfach geschreiben beim definitiv nur mit 16bpp arbeitenden Hero genauso!

Wenn die Hardware es hergibt (davon gehe ich aus) kannst du natürlich mit Rootrechten dein System irgendwie zurechthacken. Kannst ja z.B. mal versuchen fbset drauf zum Laufen zu bringen. Innerhalb des Androidsystems geht es aber nicht, auch nicht mit dem NDK.

ich persönlich kann mir gut vorstellen, dass diverse programme (z. B. das standardprogramm für bildanzeige oder der videoplayer) nativen code im hintergrund ausführen zur ausgabe und das javazeugs nur zur steuerung dient.

Klar, und Android zeichnet derweil wohin? Mit Verlaub, das ist Blödsinn, der alleine schon auf Grund des Rechtesystems nicht denkbar ist!

mit gewissheit kann ich sogar sagen, dass die codecs nicht in java programmiert sind.

Und das ist eine ganz andere Sache: Ob die Bitmaps nun in Java, C++, Assembler oder direkt aus Orgonenergie heraus generiert werden ist einfach unerheblich.

Grüße, Felix

 

[Gdroid]

Wer sagt, dass das Hero "nur" 16bpp hat? Die Specs. sicher, aber ob das auch in jeder hinsicht stimmt?

Wenn man davon ausgeht, dass Android Notebooks betreiben soll, kann ich mir kaum vorstellen, dass die Farbtiefe auf 16bpp beschränkt ist..

Gibt es nicht ein Android welches auf PCs bootbar ist? wär ein Test wert :/

 

[sonic]

Das Dithering könnte von Toshibas "Magic Square algorithm" des vielleicht verbauten TC358720XBG kommen. Das Panel scheint auch nur mit 18 bit an diesen angebunden zu sein:

# mount -t debugfs none /sys/kernel/debug/
# cat /sys/kernel/debug/msm_fb/0/bpp
18

Dieser wäre auch gar nicht in der Lage, ein Panel mit 24 bit anzusteuern.

 

[fexpop]

Das Panel scheint auch nur mit 18 bit an diesen angebunden zu sein:

# mount -t debugfs none /sys/kernel/debug/
# cat /sys/kernel/debug/msm_fb/0/bpp
18

Dieser wäre auch gar nicht in der Lage, ein Panel mit 24 bit anzusteuern.

Das klingt ja auch sehr interessant!

Danke, Felix

 

[Gdroid]

Seltsam diese ganze Geschichte!

Man fragt sich ausdrücklich warum Samsung überhaupt auf die Idee kommt mit 16.1 Mio Farben zu werben..

Das T-Mobile Pulse, das im Oktober kommen soll, hat anscheinend "auch" 16.1Mio Farben..mal sehen!