Forum: PC Hard- und Software viele, viele Cover's clever speichern und laden


von Julian W. (julian-w) Benutzerseite


Lesenswert?

Hallo,
könnt ihr mir Tipps geben, wie ich am besten viele kleine Bild-Dateien 
speichern kann? Ich entwickele das ganze in C#.

Zur Zeit bin ich bei etwa 2.000 JPEG-Bilder mit je etwa 20-30kB. Diese 
müsste ich alle so schnell wie möglich in den RAM bringen.

Ich denke mal 2.000 Bilder "einfach" in einen Ordner zu schmeißen, 
dürfte nicht die beste Möglichkeit sein. Doch wie löse ich das sonst? 
Klar, ich kann Unterordner anlegen, aber trotzdem muss ich ja immernoch 
2.000 Datei-Streams öffnen, lesen und schließen, was sicherlich nicht 
sehr schnell sein dürfte.

Also, evtl. könnt ihr mir da ja weiter helfen. Würde es evtl. z.B. mit 
einer SQLite-Datenbank besser geh'n, wenn ich die dafür "missbrauchen" 
würde?

Freu mich schon auf euere Vorschläge.

MfG
Julian

von Torsten K. (ago)


Lesenswert?

Kein direkter Lösungsvorschlag, aber schau doch mal wie Amarok 
(http://amarok.kde.org) das macht.

Ich würde die Files vermutlich beim ersten mal "cachen", also eine Art 
mmap aufbauen (ein File von ~30MB größe wo alle Bilder drin sind, und 
dazu einen Index mit den Dateinamen und position innerhalt des 
cachefiles. Dazu hash).

von Klaus W. (mfgkw)


Lesenswert?

alle in eine Datei und als memory mapped file in den Speicher 
einblenden.

Das wäre zumindest in C das schnellstmögliche, ob das in C# geht
weiß ich nicht.

von Klaus W. (mfgkw)


Lesenswert?

PS:  Torsten meint das ja auch.
Hatte ich nicht gelesen, sorry.

von MaWin (Gast)


Lesenswert?

> Würde es evtl. z.B. mit einer SQLite-Datenbank besser geh'n,

Wir wissen zwar nicht wozu das alles sinnvoll sein soll,
weil du natürlich zu faul warst über das Problem was zu schrieben,
aber wir nehmen mal an es geht um etwas wie einen MP3 Player,
und wundern uns zwar wieso mehr als ein Cover, nämlich das des aktuell 
gespielten Songs, im RAM sein sollte, aber auch das scheint irgendeinen 
dummen Grund zu haben über den du uns natürlich nichts geschrieben hast.

Am schnellsten liest du 50MB ein, in dem du eine einzige Datei 
sequentiell liest, weil dann der Sektorzugriff per FAT etc. optimal 
gecacht und ge-pre-fetcht werden kann.

Das ist sogar etwas schneller als wenn du nur den Speicherbereich auf 
die Datei mappst, vorausgesetzt du musst wirklich jetzt auf die Daten 
zugreifen, denn das Mapping produziert page faults die alle einzeln 
bearbeitet werden müssen.

Wie viel langsamer es aber ist als ein Verzeichnis von 2000 Dateien 
sequentiell zu durchforsten und jede Datei einzeln zu lesen, hängt auch 
vom Speichermedium ab. Ja, es ist langsamer, aber vermutlich erträglich. 
Zumindest wäre so was einfacher zu verwalten wenn Bilder hinzukommen 
oder entfernt werden.

Wenn du nur EIN Bild (eben das zum aktuellen Song) aus den 2000 laden 
willst, ist immer noch ein Verzeichnis absolut tauglich, aber du 
könntest z.B. nach Anfangsbuchstaben in 26 Unterverzeichnisse gehen und 
nach dem zweiten Buchstaben in eine weitere Stufe damit du quasi einen 
Index für den Zugriff auf EINE Datei hast ohne alle 1999 Dateinamen in 
einem Verzeichnis sinnlos zu durchsuchen.

von Julian W. (julian-w) Benutzerseite


Lesenswert?

Hallo,
ja, das ganze ist für einen "MP3-Player", jedoch der etwas besonderen 
Art, ist mehr ein "Just for Fun - Cooler Look"-Projekt.
Ich brauche daher alle Cover's im RAM, da ich zum einem Cover-Flow über 
zwei 22°-Monster betreibe (und da die Cover's je nach Benutzer recht 
schnell "durchrasen" und es nicht ruckel'n soll, müssen die halt alle 
schon bereit stehen) und zum anderen erstelle ich eine Liste aller 
Alben, halt mit den Cover's, und wenn man bei 2x 22° scrollt, brauch ich 
die Cover's ebenfalls verdammt schnell, damit es nicht ruckelt. Keine 
Angst, es gibt "für den Benutzer" natürlich eine kleinere Ansicht, die 
Monster-Ansicht nutzt eigentlich nur der Computer, wenn er zum nächsten 
Album springt, sieht halt cool aus ;)

Also im großen und Ganzen brauche ich eigentlich immer alle Cover's 
direkt abrufbereit, daher wollte ich die gleich beim Programmstart in 
dem RAM laden.

Hab das ganze jetzt mal mit der "alles in einen Ordner"-Methode probiert 
und in einer SQLite-DB einen Index angelegt. Das ganze geht doch 
schneller wie gedacht, also es ist eigentlich noch verschmerzbar, auch 
wenn es wohl mit euren Tipps schneller geh'n würde. Aber gut, ist nur 
der Programmstart^^

Von daher lass ich es jetzt erst mal so und werde später mal die von 
euch erwähnten Methoden anschauen, und auch mal etwas Amarok 
"untersuchen".

Auf jeden Fall schon mal Danke für eure Hilfe :)

Viele Grüße
Julian

von Coda (Gast)


Lesenswert?

Was für eine API benutzt du denn? OpenGL?

von Vlad T. (vlad_tepesch)


Lesenswert?

Julian W. schrieb:
> ch brauche daher alle Cover's im RAM, da ich zum einem Cover-Flow über
> zwei 22°-Monster betreibe

vermutlich meinst du 22".
wie aber denkst du, dass ein 15kB Albumcover auf einem 22 Zöller 
aussieht?
Tip: fängt mit sch an und hört mit eiße auf


Was spricht denn dagegen am Programmstart die Bilder im Hintergrund zu 
laden?

andererseits:
.Net hat doch da bestimmt auch eine Lösung um Programressourcen in einer 
Datei zu verwalten und zu laden.
vorteil von so was ist, dass die Zuigriffsmechanismen schon vom 
Framework bereitgestellt werden.
Füg halt neue Cover, immer mit in die Datei.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

MaWin schrieb:
> Wenn du nur EIN Bild (eben das zum aktuellen Song) aus den 2000 laden
> willst, ist immer noch ein Verzeichnis absolut tauglich, aber du
> könntest z.B. nach Anfangsbuchstaben in 26 Unterverzeichnisse gehen und
> nach dem zweiten Buchstaben in eine weitere Stufe damit du quasi einen
> Index für den Zugriff auf EINE Datei hast ohne alle 1999 Dateinamen in
> einem Verzeichnis sinnlos zu durchsuchen.

Bei aktuellen Dateisystemen (NTFS nehme ich an, wenn C#) ist das nicht 
nötig, da die Verzeichniseinträge sowieso in einem B+-Baum o.ä. 
verwaltet werden.

von Julian W. (julian-w) Benutzerseite


Lesenswert?

Vlad Tepesch schrieb:
> vermutlich meinst du 22".
> wie aber denkst du, dass ein 15kB Albumcover auf einem 22 Zöller
> aussieht?
> Tip: fängt mit sch an und hört mit eiße auf

Wer sagt denn, dass ich das 200x200 große Cover auf 1680x1050 ziehe ;)
Aber einige Cover's (nicht viele, etwa 50 Stück, meine Lieblings-Alben 
eben) hab ich auch in hochauflösender Form vorliegen, die Stelle ich 
dann in Vollbild dar und dass sieht ganz brauchbar aus.

Aber was denkst du, wie viele Cover's auf 1680x2100 passen, und stell 
dir vor, da scrollst du noch mit richtig Tempo durch. Also da muss ich 
schnell Bilder nachliefern können, sonst ruckelts.


Coda schrieb:
> Was für eine API benutzt du denn? OpenGL?

Als API zum zeichnen benutze ich DirectX, zur Sound-Wiedergabe BASS. 
Aber fragt mich nichts zu DirectX, das ist alles im Grunde nur 
"geklauter Code", aus etlichen Tutorials, so wirklich durchblicken tu 
ich den noch nicht und aus "Urheberrechtlich" Sicht wahrscheinlich auch 
nicht für eine Veröffentlichung brauchbar. Außerdem funzt der Code nur 
auf meinem PC, auf meinem Laptob will's einfach nicht laufen, keine 
Ahnung, warum.
Aber das ganze DirectX "Gekritzel" setzt auf die API eines "MediaCenter" 
auf, dass ich selbst entwickle, und als Freeware, evtl. auch openSource, 
veröffentlichen werde.

Also keine Angst, dass ganze ist nicht nur Just for Fun, nur wenn man 
Monatelang mit der Programmierung zubringt und das ganze so nach 
"0815"-Standard-Player aussieht und man nicht weiß, was für besondere 
Mechanismen im Hintergrund arbeiten, hat man irgendwann das Verlangen, 
seinem Programm doch einen besonderen "Touch" zu geben. Daher diese 
bunte Cover Geschichte.

Falls ihr euch fragt, was das besondere an dem Programm ist, dann kann 
ich euch hier weiterhelfen. Das Programm läuft nämlich nur als "Client", 
daher Cache ich auch die Cover's lokal, da diese aus dem Internet 
kommen. Das ganze MediaCenter läuft nämlich als 
Server-Client-Architektur.
Dabei gibt es einen "zentralen" Server, eine MySQL-DB. Diese enthält 
alle Songs, Alben, Interpreten, Filme, Geners, usw., die im System 
vorhanden sind. Die Medien-Dateien selbst sind per http erreichbar und 
können auf ganz unterschiedlichen Servern liegen, so liegen z.B. alle 
Filme bei mir auf einem http-Server im lokalen Netz, die komplette Musik 
auf einem vServer. Als http-Server setzt ich lighttpd ein, aber mit 
mod_secodownload, ansonsten könnte ja jeder die Dateien abrufen, was ja 
nicht im Sinne des Erfinders ist^^
Alle Lieder werden also aus dem Internet geladen, dabei wird natürlich 
clever gecachet, ist z.B. der aktuelle Song fertig gecacht, so wird als 
der in der Playlist nächste und übernächste Song jeweils 10s gecacht. 
Ist das getan und es steht immer noch Bandbreite zum Download zur 
Verfügung, cacht er wiederum das nächste Lied und immer so weiter, bis 
die 100MB (oder wie viel man dem Programm halt gewährt) Cache, der im 
RAM liegt, voll sind.
Des weiteren hab ich noch einen kleinen http-Server in das MediaCenter 
integriert, der eine für das iPod/iPhone optimierte Seite ausgibt, womit 
man die Wiedergabe "primitiv" steuern kann. So was ähnliches wie iTunes 
DJ halt, nur momentan kann man die Playlist noch nicht bearbeiten. Steht 
aber auf der ToDo-List.
Und zu guter Letzt sollt das Projekt noch meine via RS232 angebundenen 
RGB-Led's passenden zur Musik ansteuern, wobei das noch in den 
Kinderschuhen steckt, wird wohl eher auf sowas wie 'ne Lichterorgel 
hinauslaufen, da BMP-Erkennung nicht wirklich funktioniert und ich ohne 
brauchabren BMP nicht weiß, wie ich einen Algorithmus entwickeln soll, 
der die LED's bunt blicken lässt :/.

So, viel Text, deswegen hier mal ein Screenshot, ist aber nicht ganz 
aktuell:
http://data.projects-tutorials.de/screenshot.jpg

Viele Grüße
Julian

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.