Ultragyors képkezelés (ASM + Delphi)
2006-10-17T08:32:55+02:00
2006-11-02T11:01:13+01:00
2022-07-26T13:46:14+02:00
  • Megnéztem a Gabest-féle tömörítést, nekem sajnos nem jó. Veszteségmentes átvitelre van szükségem. Eközben már elkezdtem felgöngyölíteni a "képmentes" különbségképzés gyors eljárását... További infók a tudástárban.
    Jelenleg ott tartok, hogy két képnek már 60 ms alatt tudom képezni a különbségét, csak le kéne még tömörítenem.

    Ettől függetlenül ha valakinek van ötlete arra, hogy KÉPKÉNT hogyan lehetne gyors különbséget képezni, kérem ne tartsa vissza...
    Mutasd a teljes hozzászólást!
  • Kérnék mindenkit, hogy térjünk vissza a témához. Nem szeretném, ha offtenger lenne belőle.
    Mutasd a teljes hozzászólást!
  • kedvencem

    guest
    0610
    Mutasd a teljes hozzászólást!
  • Eszrevettetek hogy a gepek nagyreszen ugyanazt a munkat vegzik mint 10 eve csak 100* gyorsabb gepen?

    pl nem ir tobb levelet egy titkarno, vagy nem add ki tobb szamlat egy veg attol hogy lecserelte a p1-et p4-re.

    csak eppen a szuper tok jol optimalizalo, szuper algo-t hasznalo forditok/programozok lettek sokkal benabbak.
    Igy megabajt alatt nincs program es meg a hello world-nek is p4 es proci kell
    Mutasd a teljes hozzászólást!
  • Én például arra gondoltam, hogy két emberke azt a feladatot kapja hogy számítsa ki x = 1-től 100000-ig, z = 4 y = 5 értékekre ezt:

    (5*x*x + 6*(x*y*2 + 10*z) - 12*x*y - 60*z)/x

    és az egyik C-ben a másik asm-ben kezd neki, de az egyik nem veszi észre, hogy elég csak annyit kiszámolni minden ciklusmagban, hogy 5 * x, akkor tök mindegy milyen nyelven írjuk meg, ugyis az algoritmus fogja eldönteni melyik fut le hamarabb.

    Ha pedig ugyanazt az algoritmust programozzuk le c-ben és asm-ben természetesen az asm-es gyorsabb lesz, és a c fordító által generált kódban több utasítást kell majd végrehajtania a cpunak, de ez 3.0 ghz esetében igen csekély különbség lesz időben.
    Mutasd a teljes hozzászólást!
  • Szerintem meg érdemes ötvözni a kettőt a megfelelő arányban, ha az ember igazán gyors és KÖNNYEN KEZELHETŐ kódot akar. Ezzel csak az a baj, hogy már rég volt az ASM nekem, és akkor sem műveltem túl magas szinten. Márpedig így nehéz.
    Mutasd a teljes hozzászólást!
  • egy jó magasszintű nyelven írt algo le tud verni egy asm-eset


    na ja az asm meg le tudja verni a gepi kodot :]]]]
    Mutasd a teljes hozzászólást!
  • Ma már ez van, egy jó magasszintű nyelven írt algo le tud verni egy asm-eset:)


    Ez jó önigazolásnak. Ha ezt akarod hinni hát legyen....
    Mutasd a teljes hozzászólást!
  • A mai CPU-knál ha gyorsítani akarsz, akkor azt már inkább algoritmus optimalizálással teszik a magas szintű nyelven, az asm helyett. Ma már ez van, egy jó magasszintű nyelven írt algo le tud verni egy asm-eset:) De az asm tudásnak mégis megvan az az előnye, hogy utána az ember teljesen másképp gondol egy magasszintű nyelvre (pl. C) jobban megérti a működését és szebb kódot tud benne írni.
    Mutasd a teljes hozzászólást!
  • Hi!

    Sajnos nem DIB-et, hanem DDB-t ad vissza.

    Hogy mire nem jo a google
    Manipulating Pixels With Delphi's ScanLine Property
    Koders.c'mon
    Bár az utóbbi nem biztos.
    Mutasd a teljes hozzászólást!
  • Sajnos nem DIB-et, hanem DDB-t ad vissza. Ahhoz hogy DIB legyen belőle, konvertálgatni kell. :(

    A videotömörítéses linked még megnézem :) Köszi!
    Mutasd a teljes hozzászólást!
  • Hi!

    Szerintem nem olvastad el (figyelmesen) az előzményeket...

    De. de. de.

    ha a képet tisztán lementem egy Bitmapba, akkor az nagyon gyors.

    1. Nem DIB-et add vissza? Azt a bitmapot miként lehet elérni???
    Azért jó a C nyelv, mert az ilyen manuális "eléréshez" csak egy *(ptr+eltol) kell. A ScanLine-t pedig "megirhatom".

    Ha a szerveren egy videotömörítést futtatsz pl. GABEST félét???
    A videotömörítés megoldja a képváltozás problémáját.
    Mutasd a teljes hozzászólást!
  • Nem tudom...
    Mutasd a teljes hozzászólást!
  • Na most meg lelkiismeret furdalásom van az előbbi beszólásom miatt...
    Mutasd a teljes hozzászólást!
  • Na ja, tudja, csak éppen az 1.3-at nem tudja eltárolni...
    Mutasd a teljes hozzászólást!
  • Igen igen :) Ismerem a sztorit is. (Nameg Neumann is megmondta: fölösleges a tizedesvesszővel bíbelődni, a programozó úgyis tudja, hol van...)

    Nem baj, azért köszönöm... Nincs kizárva, hogy még a Te megoldásod vezet megoldásra, de lehet, hogy kicsit több idő kell majd neki
    Minden fejleményről beszámolok.
    Mutasd a teljes hozzászólást!
  • Pojén.
    Mutasd a teljes hozzászólást!
  • Keverem a tizedmásodpercet a századmásodperccel... (ezért ragaszkodom a standardokhoz lásd: ms - Valamelyik EU-s rakéta azért robbant fel, mert az egyik fiúka font-ban a másik kg-ban számolt... ).
    Mármint 100ms. Na igen az már sok.
    Hát nincs ötletem. Ennyit tudtam segíten.
    Mutasd a teljes hozzászólást!
  • Akkor is.

    Szerintem meg elég sok... Gondolj bele, így maximum 6-7 fps-t tudnék elérni a szerver szűk keresztmetszete miatt (arról nem is beszélve, hogy több kliensnek is küldheti a képet). Hiába nem kell küldeni akár semmi új infót (nem változott a kép), akkor is nagyságrendileg 1 tizedmásodperc, hogy ezt el tudja dönteni. A kép lelopását és az előző állapothoz képest történő változásokat meg kéne tudni határozni néhány századmásodperc alatt, hogy inkább a sávszélesség legyen a szűkebb keresztmetszet, így elméletileg akár 20-30 fps-t is el lehessen érni.

    A latency localhoston kis kép esetén nagyon karcsú: amikor PNG-t küldtem (amx pár 10 kByte), az egész kb fél tizedmásodperc lehetett. A tömörítetlen anyag ehhez képest nagyon sokáig megy át. Egy teljes 1024x768-as tömörítetlen kép átpaszírozása másfél másodpercig tart, egy átlagos ablaké fél másodpercig. Ebbe csak a szerveroldal van beleszámolva, tehát amíg elküldte teljesen, addig számoltam. A másik gépen (a kliensen) nem végeztem még méréseket, mivel ha már a szerver is lassú, akkor borul az egész.
    Mutasd a teljes hozzászólást!
  • off:
    erre gondoltam a PC kepernyo copy palmtopra gondolattal
    Mutasd a teljes hozzászólást!
  • Akkor is konvertál, ha 32bites képet adsz át neki?
    Szerintem nem sok az az 1 tizedmásodperc. Mennyi az egész latency-je, amig a másik gépen megjelenik (átküldéssel, mindennel együtt)?
    Mutasd a teljes hozzászólást!
  • Ird meg Nekem, mikor nem veszitesz msecet?


    Szerintem nem olvastad el (figyelmesen) az előzményeket...
    Mégegyszer: ha a képet tisztán lementem egy Bitmapba, akkor az nagyon gyors. Viszont ezzel nem tudok tovább dolgozni, mivel a ScanLine-hoz konvertálnom kell (nem megy pfDevice-szal), a Canvas.Pixels felejtős, a Graphics32 szintén konvertál. Egy az egyben meg nem küldhetek át képenként MegaByteokat, mindenképp kezdenem kell vele valamit. Ha képként nyúlok hozzá, konvertálnom kell valamilyen fix színmélységre. Ezzel sok idő elmegy. Ha nem képként kezelem, akkor meg nehézkesebb (folyamként vagy hasonló módon).

    Akkor lennék a legboldogabb, ha valahogy a Graphics32-beli TBitmap32-be bele lehetne tenni úgy a TBitmap tartalmát, hogy ne tartson neki annyi ideig. Ha ez meglenne, nyert ügyem lenne.
    Mutasd a teljes hozzászólást!
  • off:
    Ezek nem a "képet" küldik át, hanem az ablak generálást!
    Mutasd a teljes hozzászólást!
  • Hi!

    Ird meg Nekem, mikor nem veszitesz msecet?
    A színmélység mennyire fontos, mert pl. a 15-16 vagy a 32 a cool.
    Mutasd a teljes hozzászólást!
  • Ez így logikus is, viszont hiába tudom a korrekt színmélységet, ugyanis amíg a kép pfDevice, a ScanLine hátast dob tőle. Ha meg konvertálom (PixelFormat:=pf24bit), akkor ugyanott vagyok, ahol a part szakad, ugyanis egy tizedmásodpercet elvesztek a konvertálással még akkor is, ha a forrás mondjuk 32 bites volt és 32 bitesre konvertálom, szemléletesebben:

    Windows 32 bites, device = 32 bit
    Bitmap.PixelFormat = pfDevice --> Bitmap.PixelFormat := pf32bit (1 tizedmásodperc ekkor is!)

    Kipróbáltam, ha 16, 256, stb. színűvé konvertálom, akkor is ennyi ideig tart neki...
    Mutasd a teljes hozzászólást!
  • Hi!

    mivel a lelopott kép PixelFormat típusa alapból pfDevice.

    1. A pfDevice színmélységét be lehet állitani.
    GRAPHICS.PAS include pfCustom, pfDevice, pf1bit, pf4bit, pf8bit, pf15bit, pf16bit, pf24bit, and pf32bit.

    IMHO := A default eseten := a képernyő beállítást le lehet kérdezni (a pixel probléma így okés).
    De nézzük meg máshol.

    Na, egy prog.hu-s megoldás nem jó?
    Mutasd a teljes hozzászólást!
  • Én ezt értem, de szerintem nem lesz több a küldendő mennyiség. Minden változást úgy kezelnék ill. küldenék, hogy:
    <kezdet> <méret> <adat>
    Tehát csak a megváltozott részeket küldeném át, blokkonként. Tömörítve valahogy, akár még előtte RLE-vel, ahogy írtad is fenn, és így könnyebben kiszűrve a változásokat.
    Mutasd a teljes hozzászólást!
  • ha streamkent kezeled, akkor egy dimenziod (mivel xy keprol van szo) elvesz! igy az Y iranyu elmozdulasok detektalasa nem lesz pontos, illetve tul sok lesz a kuldendo adatmennyiseg.
    Mutasd a teljes hozzászólást!
  • Én szeparáltan kezelem az ablakokat (FindWindow, stb), nem kell a teljes képernyő.

    Kipróbáltam a Graphics32-t. Állati jó, csak az a baj, hogy ez is konvertál, már a betöltéskor is. Így aztán ez is 1 tizedmásodperc, míg egyáltalán bekerül a memóriabeli TBitmap32 objektumba, igaz onnantól nagyon gyors. (Megnéztem, az assembly mellett használja az Ivn által említett BitBlt API függvényt is előszeretettel.)
    Tehát... vagy meg kell erőszakolnom a kódot és kiiktatni belőle a konvertálást, amire elég kevés esélyt látok, vagy más oldalról kell megközelítenem.

    Pl. elmentem egy TBitmap-ba, ez még teljes képernyő esetén is csupán 2 századmásodpercig tart. (Hűha! ) Utána streamként kezelve megnézni a különbségeket (kit érdekel, hogy kép ugye ), és esetleg még erre rányomni egy RLE-t, végül ezt küldeni át TCP/IP-n, persze megfelelő információk mellett.
    Ekkor nem konvertálgatok semmit, sima adatfolyammá egyszerűsödik az egész, aztán majd a kliens a túloldalt összepakolja magának a képet a kapott infókból.
    Vélemény?
    Mutasd a teljes hozzászólást!
  • Bár talán alphára nincs is szükség, lehet 24 bit elég.
    Mutasd a teljes hozzászólást!
abcd