Szkeptikus voltam és most is azt mondom, hogy ha majd én a kezemben fogom. (A content aware fill is ugyanilyen volt, azért rá kell érezni arra, hogy mikor működik, viszont remekül demózható bizonyos típusú felhasználásokra.)
Alapvetően kontúrkereséssel az elmozdulás határait és középpontját még egyszerű megtalálni. Pontszerű dolgok megkeresésével az elmozdulás irányát is, de még akkor is hiányzik az elmosással elvesztett eredeti részletek többsége… Rengeteg lokális pár pixelt átfogó kontent aware fill volna a trükk a végén?
angelday, az abstract elso mondata: “This paper presents a fast deblurring method that produces a deblurring result from a single image of moderate size in a few seconds.”
Azért van pár gyengesége a megoldásnak. Minél több éles szél található a képen, annál jobb eredmény születik. Viszont az erős zajjal, beégett részekkel és az adott képen több eltérő motion blur-rel(értsd: nem csak a kamera, de a téma is mozog) nem tud mit kezdeni.
Ettől függetlenül van jövője, bár közel sem akkora, mint hirdetik (lsd. content-aware fill).
Ezekhez iszonyatos számítási kapacitás kell – de ez meg is van.
Még nagyon régen Amigára (MC68000 @ 7.16 MHz) írtam egy sima blurt (asm, jó lassú lett; nem konvertáltam chunkyra, hanem on-the-fly olvastam mindig a bitplane-eket), és bennem is ez van meg, hogy egy blur az számításigényes (még ha rendesen meg is van írva). Azt az egyet elfelejtjük, mert elfeledtetik velünk a Java-s meg DotNet-es szánalmas hatásfokú rendszerekben megcsinált UI-k, hogy azóta a gépek teljesítménye is iszonyatos mértékben megugrott. Olyan dolgokra van gépidő, amiről eddig nem is álmodhattunk. Ráadásul a képfeldolgozás pont olyan terület, ahol a többmagos procikat ki lehet használni. Ha minden pixelhez hozzá kell nézni egy másik kép minden pixelét, régen az egy évig tartott. Ma viszont bevállalható.
Lehet, hogy a zenék meg a csajok régebben jobbak voltak, de a képfeldolgozás nagyon elhúzott.
szerintem is fog ez működni, bizonyos megkötésekkel input oldalról, ahogy a content aware fillnél, vagy a slow motion plugineknél (pl: http://www.revisionfx.com/products/twixtor/ ).
marchello: ami a Rendering Synthetic Objects into Legacy Photographs-t illeti, én szkeptikus vagyok. Nagyon csiribí-csiribá módon működik az egész és a leírásokban se nagyon részletezik a készítők a hátterét a dolgoknak. Például a fények pozíciójának és egyéb paramétereinek kinyerése egy kép alapján már megérne egy külön előadást, de érdekes módon erről se sokat tudni, csak azt, hogy az ő megoldásuk jobb annál, mint amit mások használnak.
@_alesi_: nem tudom milyen megoldások léteznek még ezen kívül. nekem az tetszik benne, hogy sitty-sutty pár vonal, sík, fényforrás megadása után —> vanishing point, perspektíva megvan, cg elem be. kész, slussz passz. és az eredmény jól néz ki.
sIBL-től tudok még, de az bevilágításra jó és nagyfelbontású HDR-ek kellenek hozzá. viszont szép eredményt ad.
lehet a különböző szoftvercsomagokban vannak erre már eszközök. nem tudom. én blendert használok. amatőrként.
Én meg azt várom, amikor mint a CSI-ben, a képen szereplő faszi napszemüvegéről visszaverődő másik ember napszemüvegéről visszaverődő képet látjuk. És mondjuk az alapkép VGA felbontású, a végeredmény meg 14 megapixeles. Na, azt szeretném én látni.
Nem bonyi igazából az a bruteforce algoritmus, ami ezt megcsinálja, csak nagyon számításigényes. Mondjuk a 4 magos procik idejében ez szerintem néhány másodperc alatt lefut majd.
Én már azt várom, amikor a fényképező ezt az anti-blur filterezési eljárást hardverből tudni fogja.
Szerintem az lenne a királyság amikor egy elrontott kép után megnyomok a fényképezőn egy plusz gombot és kijavítja a képet és nem kell azon szenvednem hogy hátha úgy marad a lefényképezendő téma még addig a két másodpercig amíg új képet készítek. És nincs kedvem utólag photoshoppolni a képeket, csak szimplán nézegetni akarom őket és élvezni az eredményt.
moszat: ezt most is tudják a gépek, optikai képstabilizátor a neve Amúgy az ilyen szoftveres megoldások soha nem adnak igazán jó eredményt, lsd. a fenti képet.
Kicsit átgondoltam, és ha jól gondolom, ez csak motion-blur-re megy. pl Gaussian blurre nem. Az algoritmus először detektálja a bemozdulás-pályát (ez látszik a videón is, kicsi kunkori görbe), majd olyan modellt épít fel, amely szerint az elmosódott kép a bemozdulás-görbe mentén szuperponált ugyanazon éles képek összessége. Ha a bemozdulás-görbe pontos, abból már jól vissza lehet állítani az eredeti képet.
Btw. a videon valami szoftveres képstabilizálási nyomok láthatóak. Még az is lehet, hogy deblurring is. Nem tudom, hogy ez hivatalos video-e, de el tudom képzelni, hogy a valóságban durván rángatták a kamerát a felvétel közben.
Nem szaporítok szót, de mi van a nagy mélységélességgel lőtt bemozdult képek esetén? A szoft honnan tudja, hogy a kép bizonyos részén DEFÓKUSZÁLTSÁG miatt van homály, hiszen ott nincsenek “éles” kontúrok. Mondjuk a bemozdult homály kb ugyanúgy néz ki, mint az “éles”, tehát ha azt a rész nem “javítja” ki, akkor sincs baj, de az éles-defókuszált kontúroknál lehet gond. És az objektív torzítást plö hogy veszi figyelembe? Amikor a kép a sarkai felé erősen vignettál, aberrál??? A referencia képről semmit sem tudunk, az EXIF-ben zérus adat van. Szkeptikus vagyok, de ne legyen igazam!
Ésmégvalami. A példafotón az ég konkrétan be van égve, vagyis olyan brutál jó fényviszonyok között “sikerült” bemozdult képet lőnie valakinek, hogy azt a nagymamám se tudná utánuk csinálni, ha még élne. Ilyen látószöggel, ekkora fénynél csak ultragagyi géppel lehet ennyire bemozdult képet lőni, SZÁNDÉKOSAN. Miért nem valami nagyzoomos, zajos, szar fényviszonyok között lőtt képpel demóznak??? Több sebből vérzik…
@ern0 a te blur algoritmusod az vszleg a “naiv” implementáció volt, abból van olyan algoritmus, ami konstans sebességgel számol bármekkora blurt. manapság pl. kb. az összes valamirevaló kompozitáló szoftver azt használja.
Sajnos olvasói levelekre nem áll módunkban egyesével, kimerítő módon reagálni, privát segítséget nyújtani, kérdésekről véleményt alkotni. Reklámanyagokat lehet küldeni, de ezzel kapcsolatos poszt-elvárásokat megfogalmazni teljesen felesleges.
Hozzászólásokat, véleményeket az egyes posztokkal kapcsolatban nyilvánosan itt már nem lehet írni, viszont emailen szívesen veszünk minden kiegészítést.
nem tudom, valahogy képtelen vagyok elhinni… :S
Szkeptikus voltam és most is azt mondom, hogy ha majd én a kezemben fogom. (A content aware fill is ugyanilyen volt, azért rá kell érezni arra, hogy mikor működik, viszont remekül demózható bizonyos típusú felhasználásokra.)
Alapvetően kontúrkereséssel az elmozdulás határait és középpontját még egyszerű megtalálni. Pontszerű dolgok megkeresésével az elmozdulás irányát is, de még akkor is hiányzik az elmosással elvesztett eredeti részletek többsége… Rengeteg lokális pár pixelt átfogó kontent aware fill volna a trükk a végén?
Mindenképp tetszik, gondolkodásra ösztönző feature
Egy közel három éves technológia megérkezett a tömegekhez.
Akit esetleg érdekel, hogy mi van a háttérben: http://cg.postech.ac.kr/research/fast_motion_deblurring/
Legközelebb szerintem ezzel kampányolnak: http://youtu.be/Xx7H3VZIOP0
Ahogy a mondás is tartja: amit ma a Siggraph-on látsz, azt holnap az Adobe-Autodesk családban látod viszont.
_alesi_, biztos finomítottak rajta etc, node! A kérdés az, hogy ehhez motion gfx kell neki, vagy megeszi az állót is?
angelday, az abstract elso mondata: “This paper presents a fast deblurring method that produces a deblurring result from a single image of moderate size in a few seconds.”
Álló anyagból dolgoznak.
Azért van pár gyengesége a megoldásnak. Minél több éles szél található a képen, annál jobb eredmény születik. Viszont az erős zajjal, beégett részekkel és az adott képen több eltérő motion blur-rel(értsd: nem csak a kamera, de a téma is mozog) nem tud mit kezdeni.
Ettől függetlenül van jövője, bár közel sem akkora, mint hirdetik (lsd. content-aware fill).
Ezekhez iszonyatos számítási kapacitás kell – de ez meg is van.
Még nagyon régen Amigára (MC68000 @ 7.16 MHz) írtam egy sima blurt (asm, jó lassú lett; nem konvertáltam chunkyra, hanem on-the-fly olvastam mindig a bitplane-eket), és bennem is ez van meg, hogy egy blur az számításigényes (még ha rendesen meg is van írva). Azt az egyet elfelejtjük, mert elfeledtetik velünk a Java-s meg DotNet-es szánalmas hatásfokú rendszerekben megcsinált UI-k, hogy azóta a gépek teljesítménye is iszonyatos mértékben megugrott. Olyan dolgokra van gépidő, amiről eddig nem is álmodhattunk. Ráadásul a képfeldolgozás pont olyan terület, ahol a többmagos procikat ki lehet használni. Ha minden pixelhez hozzá kell nézni egy másik kép minden pixelét, régen az egy évig tartott. Ma viszont bevállalható.
Lehet, hogy a zenék meg a csajok régebben jobbak voltak, de a képfeldolgozás nagyon elhúzott.
szerintem is fog ez működni, bizonyos megkötésekkel input oldalról, ahogy a content aware fillnél, vagy a slow motion plugineknél (pl: http://www.revisionfx.com/products/twixtor/ ).
ezt is biztos integrálják majd valahova:
http://vimeo.com/28962540
marchello: ami a Rendering Synthetic Objects into Legacy Photographs-t illeti, én szkeptikus vagyok. Nagyon csiribí-csiribá módon működik az egész és a leírásokban se nagyon részletezik a készítők a hátterét a dolgoknak. Például a fények pozíciójának és egyéb paramétereinek kinyerése egy kép alapján már megérne egy külön előadást, de érdekes módon erről se sokat tudni, csak azt, hogy az ő megoldásuk jobb annál, mint amit mások használnak.
@_alesi_: nem tudom milyen megoldások léteznek még ezen kívül. nekem az tetszik benne, hogy sitty-sutty pár vonal, sík, fényforrás megadása után —> vanishing point, perspektíva megvan, cg elem be. kész, slussz passz. és az eredmény jól néz ki.
sIBL-től tudok még, de az bevilágításra jó és nagyfelbontású HDR-ek kellenek hozzá. viszont szép eredményt ad.
lehet a különböző szoftvercsomagokban vannak erre már eszközök. nem tudom. én blendert használok. amatőrként.
Ern0: Amit írtál az UI-król,hogy amiket most alkalmaznak, azok szarok. Milyen ami jó? Vagy ez hogy űködnek, ha akarnák a fejlesztők? Érdekes téma ez.
Én azt várom, amikor rossz felbontású videóból nagyfelbontású képet csinálnak.
Én meg azt várom, amikor mint a CSI-ben, a képen szereplő faszi napszemüvegéről visszaverődő másik ember napszemüvegéről visszaverődő képet látjuk. És mondjuk az alapkép VGA felbontású, a végeredmény meg 14 megapixeles. Na, azt szeretném én látni.
Nem bonyi igazából az a bruteforce algoritmus, ami ezt megcsinálja, csak nagyon számításigényes. Mondjuk a 4 magos procik idejében ez szerintem néhány másodperc alatt lefut majd.
Én már azt várom, amikor a fényképező ezt az anti-blur filterezési eljárást hardverből tudni fogja.
Szerintem az lenne a királyság amikor egy elrontott kép után megnyomok a fényképezőn egy plusz gombot és kijavítja a képet és nem kell azon szenvednem hogy hátha úgy marad a lefényképezendő téma még addig a két másodpercig amíg új képet készítek. És nincs kedvem utólag photoshoppolni a képeket, csak szimplán nézegetni akarom őket és élvezni az eredményt.
moszat: ezt most is tudják a gépek, optikai képstabilizátor a neve
Amúgy az ilyen szoftveres megoldások soha nem adnak igazán jó eredményt, lsd. a fenti képet.
Kicsit átgondoltam, és ha jól gondolom, ez csak motion-blur-re megy. pl Gaussian blurre nem. Az algoritmus először detektálja a bemozdulás-pályát (ez látszik a videón is, kicsi kunkori görbe), majd olyan modellt épít fel, amely szerint az elmosódott kép a bemozdulás-görbe mentén szuperponált ugyanazon éles képek összessége. Ha a bemozdulás-görbe pontos, abból már jól vissza lehet állítani az eredeti képet.
Btw. a videon valami szoftveres képstabilizálási nyomok láthatóak. Még az is lehet, hogy deblurring is. Nem tudom, hogy ez hivatalos video-e, de el tudom képzelni, hogy a valóságban durván rángatták a kamerát a felvétel közben.
Gaussian blurrel azért nem működhet, mert az eltünteti teljesen a magasfrekvenciás komponenseket.
Nem szaporítok szót, de mi van a nagy mélységélességgel lőtt bemozdult képek esetén? A szoft honnan tudja, hogy a kép bizonyos részén DEFÓKUSZÁLTSÁG miatt van homály, hiszen ott nincsenek “éles” kontúrok. Mondjuk a bemozdult homály kb ugyanúgy néz ki, mint az “éles”, tehát ha azt a rész nem “javítja” ki, akkor sincs baj, de az éles-defókuszált kontúroknál lehet gond. És az objektív torzítást plö hogy veszi figyelembe? Amikor a kép a sarkai felé erősen vignettál, aberrál??? A referencia képről semmit sem tudunk, az EXIF-ben zérus adat van. Szkeptikus vagyok, de ne legyen igazam!
Ésmégvalami. A példafotón az ég konkrétan be van égve, vagyis olyan brutál jó fényviszonyok között “sikerült” bemozdult képet lőnie valakinek, hogy azt a nagymamám se tudná utánuk csinálni, ha még élne. Ilyen látószöggel, ekkora fénynél csak ultragagyi géppel lehet ennyire bemozdult képet lőni, SZÁNDÉKOSAN. Miért nem valami nagyzoomos, zajos, szar fényviszonyok között lőtt képpel demóznak??? Több sebből vérzik…
persze nem fog minden esetben működni: http://blogs.adobe.com/photoshopdotcom/2011/10/behind-all-the-buzz-deblur-sneak-peek.html
@ern0 a te blur algoritmusod az vszleg a “naiv” implementáció volt, abból van olyan algoritmus, ami konstans sebességgel számol bármekkora blurt. manapság pl. kb. az összes valamirevaló kompozitáló szoftver azt használja.