Farben von Hintergrundbildern ändern

[Robby]

Das Problem an den Fonts/Icons besteht ja meistens darin, das man sich die aus diversen Internetseiten zusammen sucht. Für den Privatgebrauch ja kein Problem aber sie dann hochzuladen.....

[mars]

Die Icons in einen Font zusammenfassen ist ja ideal, dann sind weder Vorder- noch Hintergrundfarben ein Thema ...
... und ich habe schon mehrere Dutzend in div. Farben importiert


Ja, eine Anleitung dafür wäre toll, und evtl. gehts mit Einverstädniss der Admins auch direkt als Download des Fonts im Servicebereich.

[Robby]

Ne blöde Frage. Wie bekomme ich denn Icons in ein Font?

Kannst Du mir ne kurze Schritt für Schritt Anleitung geben?

[timberland]

Oder du packst die Icons in einen Font. Ist zwar anfangs eine wenig aufwendig...aber es lohnt sich

EDOMI_·_Visualisierung.pngEDOMI_·_Font.png

[Stoxn]

Hier mein Vorgehen auf dem Mac mit installiertem Perl und ImageMagick:

Die SVGs kannst Du z.B. von Weiß (#fff) in Rot (#f00) färben - also Suchen und Ersetzen:

perl -pi -w -e 's/#fff/#f00/g;' *.svg

Da mir die Visu mit SVGs zu langsam lädt, habe ich mittlerweile alles auf PNGs umgestellt.
Mit imagemagick kannst Du per Kommandozeile (hier Mac) einen ganzen Rutsch Bilder konvertieren:

mogrify +antialias -density 2000 -verbose -background none -size 400x400 -format png *.svg

[tger977]

ich krame diesen Thread nochmal hoch, da ich auch gerade versuche die KNX-UF Icons in meine Visu zu integrieren. Das funktioniert schon soweit,aber halt bisher alles nur "weiß". Hat es nun schon jemand geschafft diese wie am Anfang des Threads einzufärben? Falls ja, wie?

[gaert]

Klar, kommt alles...

[rdeckard]

Eine Frage zu Bildern in Edomi:
Importierte Bilder werden u.U. ja auf verschiedenen Seiten in der Visu benötigt. Und dann nicht immer in der gleichen Grösse.
Wenn ich die Maße des Visu-Elements ändere, wird ja das darin liegende Hintergrundbild entsprechend skaliert, aber ohne Einhaltung des ursprünglichen Seitenverhältnis.
Wenn das Visu-Element gleich gross wie das Bild ist, ists ja einfach. Ansonsten muss man da rumprobieren oder gar das Verhältnis ausrechnen.
Wäre es nicht möglich, beim Visu-Element eine Checkbox "Verhältnis beibehalten" einzubauen, bei der das Bild immer korrekt skaliert würde?

Da wir doch viel mit Bildern hantieren, wäre das sicher eine sinnvolle Funktion.

(Im Moment arbeite ich noch viel mit SVG. Da wird komischerweise immer korrekt skaliert. Aber eben...SVG ist ja nicht offiziell unterstützt und scheint nicht so beliebt zu sein. Werde da also wieder auf PNG umstellen, aber mit korrektem Skalieren wäre das einfacher.)

[gaert]

Die Aussage im Bild und die Farbgebung passen sogar recht gut zu KNX und damit einhergehenden Zutrittskontrollen an der Haustür...

PS: Ich habe Wolfenstein nie gespielt und nie (raub)kopiert! Niemals nie...

[MarkusS]

Nee nee nee.

Da geht es um Computer-Vintage.

Endlich eine Visu im Wolfenstein-Design von 1981!

[saegefisch]

Na, das hört sich doch noch wunderbarer an! So kompliziert wagte ich gar nicht zu denken nach Deiner ersten Zurückhaltung. Den Aspekt "gesammelter Austausch" ist auch schon drin. Na dann...sobald es irgendwann bei Dir oben auf der Liste steht: Wohl an, mein Capitän!

Vintage? Ist das das mit den Kerzen statt Glühbirne und "Musikus mit Klampfe" statt Lautsprecher?

[gaert]

Alles schön und gut - aber in meiner Pipeline ist dann eher etwas in dieser Art:

Es gibt Einzelbilder (wie gehabt) UND es gibt "Bilder-Sammlungen" (wie auch immer man das nennen wird).

Diese Sammlungen sind dann in dem Konfig-Baum nur ein einzelner Eintrag (so wie ein normales Bild). Öffnet man diese Sammlung, wird der Inhalt (also die Bilder) in einer Liste angezeigt usw.

Im Visueditor kann man dann entweder ein Einzelbild auswählen (wie gehabt) oder ein Bild aus dieser Sammlung auswählen.

Eine solche Sammlung wird intern auf Dateiebene z.B. wie ein Ordner verwaltet - für den Austausch würde ich dann einen entsprechenden Container erdenken (z.B. ein TAR/ZIP-Archiv mit einem entsprechenden Suffix).

Der Vorteil: Man "flutet" sich nicht die Konfiguration mit u.U. hunderten von Einzelbildern nebst Namen, sondern sieht in erster Instanz nur etwas wie "Iconset: Vintage"

[saegefisch]

nur so perspektivisch gesprochen...für den Tag, wo Du das doch mal angehen magst:

- Index hatte ich nicht bedacht, ich war noch auf der Schiene "name ist eindeutig". Tja, muss die DB noch mehr inhalieren... Unter der Sichtweise, dass dies ein Werkzeug ist und kein Allheilmittel (bei einer Kneifzange muss ich auch wissen oder lernen, wo ich anfasse...): Der Anwender ist dafür verantwortlich. Wenn der Dateiname einen Index "(x)" enthält oder - vereinfacht - damit endet, wird unabhängig vom bisherigen Namen das Bild mit dem selben Index ausgetauscht und mit dem neuen Namen überschrieben (Index bleibt natürlich gleich). Also würde im ZIP ein Garagentor_rot(4).jpg ein wie auch immer vor benanntes Bild mit dem Index (4) überschreiben und dann Garagentor_rot heißen. Wird kein Index mitgegeben oder existiert der Index als Bild nicht: Neuanlage mit neuem Index. Verantwortung liegt beim ZIP-Erzeuger. Wie gesagt: Es soll ein unterstützendes Werkzeug sein. Wenn man sich einmal sein Projek-ZIP zurecht geschnitzt hat, wird das wunderbar funktionieren. Und ohne Sinn und Verstand verwendet halt nicht...
Ich würde beim ersten Upload daher alle ohne Index hochladen und dann einmalig(!) mir die dann ewig stabilen Indexnummern aus edomi in die Dateinamen übernehmen und künftig Uploads so oft machen können, wie ich will.

- Ordner - Option A: ZIP wirkt bei der Neuanlage genau pro Ordner, in dem man "neu" gedrückt hat. Außer für enthaltene Dateien mit mitgeliefertem Index, dann diese natürlich genau auf den einen Index (egal wo). Auch wieder: Verantwortung liegt bei Sorgfältiger ZIP-Erstellung. Aber wenn man mal sein Projekt-ZIP geschnürt hat, kann man damit sehr zügig und scharfkantig arbeiten.

- Ordner - Option B: ZIP kann Unterordner enthalten, die DB-Struktur abbilden. Halte ich für unnötig kompliziert.

- Löschen: Das Package existiert nach der Verarbeitung nicht mehr. Es ist nur eine Upload und Aktualisierungshilfe. Keine DB-Persistenz. Daher Löschen bleibt unverändert (einzeln) wie bisher. Wer das nicht will: Besser _vor_ dem Upload von 3.000 Bilder denken, dann lenken... Oder künftig wieder einzeln hoch laden. Ohne Schmerz manchmal kein Wachstum...

just my 2 cents

[gaert]

Doch, ich verstehe durchaus Es ist ja nicht so, dass mir derartige Dinge noch nie in den Sinn gekommen wären...

Nur ist es eben nicht mal eben mit dem Entpacken einer ZIP-Datei erledigt: Die "Dateien" landen in der DB mit einem Index. Wenn ich nun die Dateien "update", ist es mit einem einfachen Austausch der Dateien nicht getan. Und was passiert, wenn ich einen "DB-Ordner" (Konfiguration) anlege? Oder lösche? Oder ich lösche das ganze Package - habe aber zig Visuelemente, die auf ein Bild "zeigen"...

Das geht alles und ist auch kein Thema - aber es ist viel Arbeit!

[saegefisch]

Dass eine DB dahinter steckt ist klar, es wäre ja auch eher eine Frontend-Sache, den aktuellen Upload-Dialog auch diesen "Container-Umweg" zu ermöglichen (also 1x 100 Bilder nur statt 100 x 1 Bild). Das Ergebnis sollte unverändert bleiben. Vielleicht hatte ich da etwas missverständlich ausgedrückt. Damit erscheint mir der Aufwand nicht fulminant, da an der Mechanik sich nichts ändert. Nur halt der klitze-kleine Umweg über die ZIP, als wenn man's manuell gemacht hätte...

Wäre schön, wenn Dir die Idee gefällt und sie auf die Roadmap käme. Für eine umfangreichere Nutzung wär's auch irgendwie wichtig. Aber ich bin mir sicher, Du weißt am besten, die richtigen Prios zu setzen.
Bis dahin ziehe ich halt weiter meine Bahnen in Edomi - ich lass' mich doch von ein paar manuellen Uploads nicht aufhalten...

saegefisch