Einzelnen Beitrag anzeigen

Benutzerbild von cumi
cumi

Registriert seit: 27. Jun 2004
Ort: Schweiz
27 Beiträge
 
#17

Re: schnellerer Zugriff auf Tbitmap

  Alt 7. Dez 2004, 15:44
Zitat von dizzy:
Na das sieht doch recht gut aus! Wenn du auf die Genauigkeit verzichten kannst: Double ist deutlich schneller als Extended. Aber grad für einen Zoom kann die Genauigkeit interessant werden (ich selbst hab bei immens starkem Zoom auch schon mal das "Ende von Double" gesehen ).
Jo wenn du mal so richtig reinzoomen willst kommst du mit den Double wirklich an den Anschlag... Und viel langsamer wirds ja mit Extended wahrscheinlich auch nicht sein, oder?

Zitat von dizzy:
Den Alphateil kanst du ganz weg lassen, ja. Der sollte dann imho auf 255 gesetzt werden. Der wird erst interessant wenn du mehrere Bitmaps halbtransparent überlagern möchtest. Allerdings kann man ihn nicht ganz weg lassen, d.h. ein Pixel wird immer volle 32 Bit beanspruchen. Deshalb ja auch Graphics32 .
Die gesamte Sequenz im RAM zu halten ist imho ohnehin nicht so glücklich. Über Chunks von so 10 bis 20 Bitmaps im Speicher kann man reden, die dann in einem Schwupps geschrieben werden, aber ich hab jedes Bitmap direkt nach Fertigstellung weggeschrieben und fertig.
Äh also bis jetzt hab ich ihn einfach immer gar nicht berücksichtigt. Daher wird er höchstwahrscheinlich auf 0 stehen... Funktioniert aber trotzdem. Kann aber auch sein das die Funktion Color32 den Alphawert automatisch auf 255 setz.
Nun du sagtest dieser werde für die Transparenz benutz. Wie funktioniert das? Mir ist gleich die Idee gekommen, dass ich eigentlcih übergänge von einer in die andere Farbe so rechnen könnte. Äh also mal eine Idee wie ich mir vorstellen könnte wies gehen könnte Kann man einfach zuerst was zeichen, sprich einen Pixel einfärben mit dem Alphawert 255 und danach den selben Pixel nochmals überschreiben allerdings mit einem Alphawert von zb. 128 und dann er der Pixel schlussentlich den Mittelwert? Naja war nur so eine Idee

Zitat von dizzzy:
Zitat von cumi:
Nun nochmals eine kurze Frage. Du sagtest du überlässt das "Filmmachen" an Virtualdub etc. Wie funktioniert das denn bei dir genau? Also Virtualdub kenn ich relativ gut. Ich benutzte es häufig zum umcodieren von Filmen. Jetzt speicherst du einfach alle Frames als Bitmap auf die HDD?
Japp, genau so
Einfach mit aufsteigender Nummereierung benennen (z.B. frac0001.bmp; frac0002.bmp; ...; fracXXXX.bmp), und VirtualDub (und auch TMPGEnc) erkennen mit Öffnen des ersten Bildes der Sequenz dass es auch eine Sequenz ist, und behandelt es wie ein Video.
Ist zunächst mal die einfachere Variante während man sich noch mit den "wichtigen" Dingen rumplagen muss 8).
Ah supi, wusste nicht das dies so einfach geht Naja wie soll man schno auf die Ideekommen eine *.bmp Datei mit VirtualDub zu laden....

------------------
Nun hab ich aber trotzdem nochmals eine Frage. Also irgendwas mach ich da noch nicht ganz richtig habe ich bemerkt. Es sind nicht einfach TBitMap32 die mehr Stack brauchen, nein ich brauche wenn ich das selbe nochmals rechne und eigentlich nicht weitere TBitMaps erzeuge (mach ich dann auch teilweise in einer doppeltverlinkten Liste. Seit ich dieses System kenne brauch ich es wo es nur irgendwie einbisschen Sinn macht weil mich die Geschwindigkeit und die Bedienung fast vom Stuhl gehauen hat ).
Ich überschreibe dabei allerdings ein vorhandenes TBitMap immer wieder. Nun der fehler muss wohl dabei liegen.
Ich mache dies so:
Delphi-Quellcode:
  img:=TBitmap32.Create; //img ist vom Typ TBitMap32
  img.Width:=sRef.dx;
  img.Height:=sRef.dy;
Ich hab dann mal zum probieren immernoch vor dem TBitmap32.Create img.free aufgerufen, was allerdings keine Abhilfe schuf.
Iregdnwer eine Idee was da sonst noch schieflaufen könnte??

Ah ja und gibts kei Tool von Delphi her welches einem anzeigt wo wieviel Speicher gebraucht wird? Ich benutze bis jetzt (ich weiss, dass es nichts dümmeres gibt ) den Taskmanager von WinXP. Ich zweifle jedoch an dessen Richtigkeit.....

Vielen Dank für eure Hilfe! Greez cumi
Lorenz
  Mit Zitat antworten Zitat