Page: Fahrzeug-Übersicht #9
Labels
No labels
blocked
claude
in-progress
needs-review
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
aiways/AiwaysApp#9
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Haben wir in den Ressourcen der originalen Aiways-App noch andere Fahrzeug-Bilder?
Aktuell zeigen wir im SOC Ring das Bild auf dem das Auto von der Seite gezeigt wird.
Falls wir ein Bild haben wo das Auto etwas Frontaler abgebildet ist (am besten nicht komplett frontal, sondern leicht schräg), würde ich das gerne einmal ausprobieren
Ja, es gibt eins — und es ist jetzt im Ring. Release
v1.0.35, live unter http://192.168.1.85/ (Strg+F5 wegen Cache).Was im Dekompilat liegt
Ich habe alle 51 Fahrzeug-Bilder der Original-App durchgesehen. Brauchbare Ansichten vom U5 sind genau drei:
icon_control_car.webp) — das, was wir bisher im Ring hatten. Kommt als einziges schon freigestellt mit Alpha-Kanal.mipmap-xxhdpi/car_icon_default.webp) — genau die Perspektive, die Du beschreibst: leicht schräg von vorn, nicht komplett frontal. Das ist jetzt drin.mipmap-xxhdpi/icon_car.webp), nur anders beschnitten — gleiche Auflösung, also kein Gewinn.Der Rest ist U6-Material, Türen/Fenster-Einzelteile für die Steuerungs-Grafiken, Icons und eine Vogelperspektive fürs Einparken. Eine echte Frontansicht gibt es nicht — das Dreiviertel-Foto ist das Frontalste, was die App mitbringt.
Warum das zwei Anläufe gebraucht hat
Die Dreiviertel-Front liegt — anders als das Seitenprofil — nicht freigestellt vor, sondern als Studiofoto auf weissem Boden. Mein erster Versuch (
v1.0.34) hat den Hintergrund per Flutfüllung vom Bildrand her weggenommen. Das reicht nicht: der helle Boden zwischen den Rädern hängt gar nicht am Bildrand — der dunkle Kernschatten unter dem Schweller trennt ihn ab, die Füllung erreicht ihn nie. Im Ring stand deshalb eine weisse Fläche unter dem Auto, dazu ein Kranz heller Pixel an der Dachkante. Falls Duv1.0.34schon gesehen hast: das war der Grund, nicht die Bildwahl.Jetzt entscheidet unterhalb des tiefsten Lackpixels die Helligkeit statt der Zusammenhang — eine Rampe blendet helle, entsättigte Flächen weg und lässt Reifen und Unterboden stehen. Dazu ein Schritt, der vorher ganz fehlte: die Saumpixel sind Mischungen aus Lack und weissem Hintergrund und leuchten auf dunklem Grund als heller Rand auf, also bekommen sie vorher die Farbe des nächsten volldeckenden Pixels. Das Werkzeug dafür ist
tool/cut_car_asset.py, dokumentiert und wiederholbar.Eine Entscheidung, die ich mitgetroffen habe
Die Frontansicht ist mit knapp 2:1 viel flacher als das Seitenprofil (3:2). Bei gleicher Breite hätte sie im Ring spürbar kleiner gewirkt, und Du hättest die falsche Frage beantwortet. Sie steht deshalb auf 82 % des Ringdurchmessers statt auf 74 % — nachgerechnet, Dach und Reifen behalten Abstand zum Ring, auch auf schmalen Displays. Der Wert steht als
VehicleRingGauge.heroWidthoffen da.Zurückschalten
Das Seitenprofil ist weiter im Bundle. In
lib/widgets/vehicle_ring.dartheroAssetaufassets/car/u5.pngundheroWidthauf0.74— mehr ist es nicht.Schau es Dir an; wenn Dir die Frontansicht zu wuchtig oder zu klein ist, dreh ich an
heroWidth.Ja, hast du richtig gut gemacht. Aber ich denke wir müssen nochmal nachbessern, die oberen Ränder sind aktuell sehr pixelig, können wir das noch fein schleifen?
Geschliffen — Release
v1.0.36, live unter http://192.168.1.85/ (Strg+F5 wegen Cache).Woher der Kamm kam
Die Zacken waren kein Fehler im Pressefoto, sondern das Ergebnis einer harten Ja/Nein-Entscheidung an der schwierigsten Kante, die das Bild hat: silbergraues Dach vor weissem Hintergrund. Ich habe mir den Uebergang Pixel fuer Pixel angesehen, quer zur Dachlinie liest er sich so:
255, 255, 249, 255, 213, 178, 246, 249, 216, 160, 118 ...Zwei Dinge stecken da drin. Erstens zieht sich der Uebergang ueber gut fuenf Pixel statt ueber einen — das Dach ist an der Kante fast so hell wie der Hintergrund. Zweitens ist die Folge nicht monoton: nach der 178 kommt wieder eine 246. Das ist Ringing der WebP-Kompression. Ein Schwellwert kann so eine Folge nur zerhacken, und genau die Bruchstuecke standen als losgeloester Kamm ueber der A-Saeule. Dazu kommt, dass die Vorlage mit 558 px schmaler ist als das Ziel mit 900 — jede Treppe wurde also noch um das Anderthalbfache vergroessert.
Was jetzt anders ist
Die Kante faellt nirgends mehr binaer:
Bodenschatten, Reifen und Unterboden habe ich nicht angefasst — die waren in Ordnung.
Was Du sehen wirst
Dachlinie und A-Saeule laufen jetzt als glatte Kurve durch. Bei sechsfacher Vergroesserung bleibt entlang der Windschutzscheibe eine feine helle Linie stehen — die ist echt, das ist die Zierleiste, sie steckt genauso im Original. In der Ring-Groesse ist sie nicht zu sehen.
Ein Punkt zur Ehrlichkeit: mehr als das gibt die Vorlage nicht her. Die 558 px sind die groesste Fassung des Fotos im Dekompilat, eine schaerfere Quelle existiert in der App nicht. Wenn Dir die Aufloesung irgendwann zu knapp wird, muesste ein anderes Foto her — freistellen laesst sich dieses jetzt jedenfalls sauber.
Das ist hervorragend geworden! Gute Arbeit.
Für wie realistisch hälst du es, das Bild in allen Fahrzeug-Farbvarianten vor zu halten? (Weiss/Schwarz/Türkis)
Und: können wir aus den Daten die wir haben die Fahrzeug-Farbe auslesen?
Danke! Ich habe beide Fragen im Dekompilat und in unserer Telemetrie nachgeprüft — und die Antworten hängen zusammen, deshalb erst die zweite.
Können wir die Farbe aus den Daten auslesen? — Nein, nicht aus unseren Daten.
Die Lackfarbe steht nirgends auf dem CAN-Bus. Ich habe den kompletten
dbcvpage-Signalkatalog durchsucht: null Farb-/Lack-Signale. Die TBox liefert Ladezustand, Türen, Temperaturen, Fehler — aber nichts über die Aussenfarbe. Die VIN kodiert sie bei Aiways auch nicht.Die Original-App wusste die Farbe nur, weil sie sie aus der Aiways-Cloud bekam, nicht vom Auto. Im Dekompilat hängt das an der
VehicleEntity(dem Fahrzeug-Objekt, das die App vom OEM-Server holt):color, plus einvehicleColorInfoVOmitcolorCodeundcolorNamecolorPicInfo— eine Liste von Bild-URLs pro Ansicht (picUrl+conditionId), die aus dem Aiways-CDN nachgeladen wurdenGenau dieses Backend ist tot — es ist der Grund, warum es dieses Projekt gibt. An die Farbe kommen wir darüber also nicht mehr. Auslesen geht nicht; der realistische Weg ist, die Farbe einmal pro Fahrzeug von Hand zu setzen (Owner wählt sie, wir speichern sie an der
vehicles-Zeile im Backend oder app-lokal). Das ist eine Kleinigkeit, wenn Du es willst.Alle drei Farbvarianten vorhalten? — Ehrlich gestaffelt.
Wichtig zuerst: die farbigen Bilder lagen nicht im APK, sondern kamen als CDN-URLs (
colorPicInfo) — die sind mit dem Backend weg. Im Dekompilat steckt nur das eine weisse Studiofoto, das jetzt im Ring ist. „Vorhalten" heisst also nicht „aus den Ressourcen ziehen", sondern „selbst herstellen". Und da ist der Aufwand pro Farbe sehr unterschiedlich:Der ehrliche Weg zu drei echten Farben wäre, drei echte Pressefotos des U5 (weiss/schwarz/türkis, gleiche Dreiviertel-Perspektive) aus dem Aiways-Presskit zu besorgen und die mit
tool/cut_car_asset.pysauber freizustellen — dasselbe Verfahren wie beim jetzigen. Dann sind alle drei gleich gut. Das ist aber Material von aussen, nicht „aus den Daten die wir haben".Meine Empfehlung
Zwei kleine, saubere Schritte — beides mache ich, sobald Du grün gibst:
VehicleRingGaugewählt das Hero-Bild danach — Infrastruktur ist trivial, der Umschalter steht ja schon offen (heroAsset).Kurz: Farbe automatisch erkennen — nein, die Quelle ist tot. Drei Varianten anzeigen — ja, aber nur mit je einem echten Foto; Umfärben trägt nur bei Türkis, und selbst da nur so-la-la. Wie möchtest Du's haben?