Příspěvky

271

Software / Re:Vytvoření AVI videa z obrázků

« kdy: 26. 04. 2017, 12:48:27 »

BlueBull

Diky, abecedne uz obrazky png pojmenovane jsou, jen ne primo v poradi Obr0001.png Obr0002.png, ale ty cisla jdou s vetsim rozestupem. Ale pro jistotu ten seznam udelam, to nezabere prakticky zadny cas.

ffmpeg -f concat -i seznam.txt -c:v huffyuv -pix_fmt yuv422p output.avi
to se jedna o ten bezstratovy kodek ?  Uvidim jak to poroste. Mozna ze i zkusim mirne ztratove video. Framerate 30 fps tam nekde pujde nastavit, tusim hned na zacatku. A rozliseni predpkladam bude takove, jako obrazky (2000x1000).

Ted uz jen pockat, nez se vse spocita.

272

Software / Re:Vytvoření AVI videa z obrázků

« kdy: 26. 04. 2017, 10:04:49 »

Doporučil bych ujasnit si pojmy "kodek" a "formát". Použil bych x264 s presetem ultrafast a malým CRF.

Ta výroba z PNG mi vyleakovala paměť, pokud se ti to stane taky, napajpoval bych tam obrázky v surovém RGB formátu.

Diky, to x264 s malym CRF by mohlo byt relativne ve vysoke kvalide, s presetem ultrafast to bude rychle.

Vedel by jsi, jak to v tom ffmpeg nastavit ? Jsem s ffmpeg uplny zacatecnik.

Surove RGB myslis BMP, ze bych to prekonvertoval nejdriv do BMP ? Pak je otazkou, jestli se obrazky musi jmenovat primo obr0001 obr0002 nebo staci abecedni pojmenovani.

273

Software / Re:Vytvoření AVI videa z obrázků

« kdy: 26. 04. 2017, 09:58:48 »

Predpokladejme ze mas obr00000.png az obr20000.png:

Pouzije se ayuv bezstratovy a nekomprimovany kodek, zachova dokonce i alfa kanal.
Vysledni soubor bude ale obrovsky (v podstate se png prevede do bmp) pocitej cca 1000Mbit/s.

Kód: [Vybrat]

ffmpeg -i obr%05d.png -c:v -c:v ayuv output.avi

Ponekud lepsi to bude kdyz se pouzije RGB bezstratova komprese podobna jako v png.
To uz budeme nekde na 250Mbit/s, co je mi znamo, avi to moc neumi, tak radeji mov.

Kód: [Vybrat]

ffmpeg -i obr%05d.png -c:v qtrle -pix_fmt rgb24 output.mov

Nejmensi velikost bude kdyz se to prevede z RGB do YUV, opet bezstratova komprese.
To budeme nekde na 150Mbit/s.

Kód: [Vybrat]

ffmpeg -i obr%05d.png -c:v huffyuv -pix_fmt yuv422p output.avi


Tak to je bezstratove video podstatne vetsi nez PNG nebo GIFy. U videa by melo jit najit podobnosti mezi jednotlivymi obrazky.

Bezstratova komprese je i animovany GIF, jenze pouze pro 256 barev (coz je u me splneno). Stejne tak jako animovany GIF existuje animovane png - MNG.

Problem u animovaneho gifu je ten, ze pri spusteni se vsechny obrazky nactou do RAM jako bmp. U kratkych animaci to nevadi, video by zabralo desitky-stovky GB RAM.

Otazkou je, jak pak je mozne z animovanym GIF nebo MNG pracovat jako s videem a konvertovat do jineho formatu.

Zarazi me datovy tok k 1000 Mbit/s. Rozliseni je 2000x1000, barevna hloubka 8 bit, pri 30 fps je i pro BMP 2000x1000x8x30 tedy 480 Mbit/s neboli 60 MB/s U barevne hlobky 24 bit je to 3x vyssi, u animovaneho gifu podstatne mene.

U schemat a grafu neni tolik barev a velke plochy jsou stejnou barvou. U fotek je kazdy pixel vicemene jinny a bezstratova komprese PNG zmensi obrazek jen na 40-60%. Video je vetsinou vicemne z fotek, proto se pouzivaji ztratove komprese.

274

Software / Vytvoření AVI videa z obrázků

« kdy: 25. 04. 2017, 14:21:52 »

Ahoj

Mam v jedne slozce vetsi mnozstvi png obrazku, rozliseni i barevna hloubra jsou vzdy stejne (2000x1000x8bit). Jedna se o modelove mapy a grafy. Pocet souboru ve slozce je 10000-20000 (vyjimecne i vice).

Chtel bych se zeptat, jak vytvorim z preddefinovane posloupnosti obrazku video s pouzitim prikazove radky. Asi nejlepsi na to bude program ffmpeg.

Musi byt obrazky pojmenovany IM0001 IM0002 atd, nebo staci abecedni serazeni. Aktualne jsou nazvy MAP${cislo}.png, kde se jedna o cela cisla, ktera ale nejdou po jedne, rozdil mezi jednotlvymi cisly jeruzny. Abecedni serazeni obrazku je totozne se serazenim podle casu vytvoreni-modifikace, a samozdrejme je totozne s tim, jak maji jit obrazky ve videu za sebou.

Posledni otazkou je, jak zvolit format. Vytvorene vido by melo byt co nevice bezstratove AVI, nevadi, ze bude velke desiky GiB, vytvorene AVI se totiz bude znovu prevadet do jinych formatu podle potreby. Uplne bezstratove-bez komprese AVI ale asi nepujde. Vlastnosti AVI - 30 fps, rozliseni 2000x1000 stejne jako obrazky, minimalni ztratovost (tedy i velke). Pocet obrazku je obvykle 1000-200000, takze doba videa bude priblizne 1-20hod. Diky za tip.

275

Vývoj / Re:Komunikace JavaScript s Bash

« kdy: 20. 04. 2017, 13:37:46 »

Diky moc

Truhe reseni funguje dobre.

Jinak pro vytvoreni nastenne mapy lze upravit skript index.js :

#!/usr/bin/env node
const Pageres = require('pageres');
process.argv
let url = process.argv[2]
let res1 = "9999x9999"
const pageres = new Pageres({delay: 2})
    .src(url, [ res1 ], {crop: true})
    .dest(__dirname)
    .run()
    .then(() => console.log('done'));

a potom zadat:

 node index.js "http://www.openstreetmap.org/"

V pripade Google Maps v index.js nastavime rozliseni:
let res1 = "4096x4096"

a po te:
 node index.js "https://www.google.com/maps/@0.0,0.0,2z"
Mapa s terenem:
 node index.js "https://www.google.com/maps/@0,0,2z/data=!5m1!1e4"
Satelitni mapu se nepodarilo vytvorit, URL je: https://www.google.com/maps/@0,0,19741474m/data=!3m1!1e3!5m1!1e4

V pripade tvorby map, hlavne OSM 9999x9999 to sezere stovky MB a asi i prez GB RAM, potreba je min. 2 GB ram v systemu.

Skript jako takovy byl ale spis urcen pro vytvoreni vetsiho mnozstvi nahledu v malem rozliseni u jednoduchych stranek. Mapy jen tak pro pobaveni.

276

Software / Re:Jak automatizovat printscreany z html stránek s obrázky

« kdy: 19. 04. 2017, 23:30:53 »

Ahoj

Koukam ted, ze jsem zapomnel dat zpetnou vazbu, diky za rady.

Resenim je take NodeJS - emulator Google Chrome.

https://github.com/sindresorhus/pageres
https://nodejs.org

Maly skript napr:

#!/usr/bin/env node
const Pageres = require('pageres');
process.argv
let url = "https://www.google.com/maps/@0.0,0.0,2z"
let res1 = "4096x4096"
let res2 = "4096x2048"
const pageres = new Pageres({delay: 2})
    .src(url, [ res1 ], {crop: true})
    .dest(__dirname)
    .run()
    .then(() => console.log('done'));

Omezeni na sirku-delku je max. 9999 pro vsechny stranky, u Google map to vypada na maximalni pocet obrazovych bodu 16 777 216, tedy 2na24.

277

Vývoj / Komunikace JavaScript s Bash

« kdy: 19. 04. 2017, 23:25:11 »

Ahoj

Mam Javaskript na par radku, ktery pracuje v programu NodeJS, vytvari nahledy html stranek (emulace prohlizece).

Kód: [Vybrat]

#!/usr/bin/env node
const Pageres = require('pageres');
process.argv
let url = "https://www.google.com/maps/@0.0,0.0,2z"
let res1 = "4096x4096"
let res2 = "4096x2048"
const pageres = new Pageres({delay: 2})
    .src(url, [ res1 ], {crop: true})
    .dest(__dirname)
    .run()
    .then(() => console.log('done'));

Jde mi konkretne o radek:

Kód: [Vybrat]

let url = "https://www.google.com/maps/@0.0,0.0,2z"

Zde bych chtel zadavat URL adresu z Bash skriptu, pomoci promennne. S Bash pracuji, ale u JS nevim vubec nic. Doposavad jsem pouze rucne upravil dany JavaScript. Adresa URL neni nutne z Google Maps, to je jen priklad. Vetsinou spis pujde o jednodusi html stranky.

Zmineny skript je index.js a spousteni jen ./index.js

Skript je zaroven resenim tohoto vlakna:

https://forum.root.cz/index.php?topic=13820.0

278

Hardware / Re:Co pouzit pro nejlepsi vypocetni vykon vs. cena a spotreba elektriny

« kdy: 09. 04. 2017, 22:07:10 »

a co chceš počítat?

Numericke modelovani, operace floating point. Mam vlastni napsane programy ve Fortranu i Octave, i vim o pokrocilejsich, jako napr. WRF, GCM. Tady bude problem floating point.

Dalsi odvetvi je vytvareni panorama z velkeho mnozstvi fotografii, hledani zmeny v zornem poli. Dale pak zpracovani videa (vytvareni ze segvence obrazku, konvert formatu).

Treti vec je parsing velkeho mnozstvi textu, html.

279

Hardware / Re:Nový notebook, lehký, dlouhá výdrž, spolehlivý, do 30k

« kdy: 09. 04. 2017, 20:32:16 »

30k je docela dost, to uz budes mit velice slusny vykon. Zalezi jak narocne ulohy potrebujes. Sehnat by slo i neco za 10-15 (20) k.

280

Hardware / Nejlepší výpočetní výkon vs. cena a spotřeba

« kdy: 09. 04. 2017, 20:29:08 »

Zdravim

Tak jsem parkrat uvazoval nad otazkou, co je nejvyhodnejsi pouzit pro vypocetni vykon (matematicke modelovani, numericke reseni, zpracovani dat, vizualizace, zpracovani obrazovych dat) k pomeru jak porizovaci cena, tak spotreba elektriny. Vzhledem k povaze zadani je paralelizace ulohy na co nejvic jader naprostou nutnosti.

1. klasicke CPU. Maximum u beznych CPU je 8 jader-16 vlaken. Vypocetni vykon desitky-stovky GFLOPS. Kdyz se ale spocte cena porizovaci a spotreba energie na 1 GFLOP, tak dobry pomer to neni.

2. GPU (CUDA). GPU maji mnoho jader (nejnovejsi okolo 3800, s fregvenci prez 1 GHZ). Vypocetni vykon je nekolik TFLOPS, spotreba energie a porizovaci cena na 1 GFLOP je lepsi nez u CPU. Pro vypocty na GPU je nutnost jineho programovaciho postupu.

3. Smarphone, ARM procesory. Vykon nic moc, ale pomer spotreba energie-vypocetni vykon je lepsi. Naopak prizovaci cena vs. vykon je drazsi. A otazkou je, jak zaizeni zvlada plnou zatez nonstop. A taky otazkou je, jak tam dostat Linux. Vyhodna je mobilita a odolnost vuci pohybu, narozdil od HDD.

4. Bitcoin miner - pri vykonu 5 THASH/s a spotrebe 1200 W je pomer spotreba-vykon velmi dobry, napodobne s porizovaci cenou. Ale vypocetni jednotka ma uplne jinou sadu instrukci, takze kdovi, jestli by sla pouzit, jako PC-server s Linuxem. Spis ne.

5. PS4 - vypocetni vykon GPU jeskutecne obrovsky, lepsi nez dosti silne PC. Pomer spotreba-vykon i cena-vykon je vyhodny. Ale otazkou je, jestli by tam vubec sel dostat Linux jakozto operacni system, a jestl by bylo mozne vyuziti jako PC-Server.

Napada vas neco jineho ?

281

Software / Re:Nejlepší nastavení komprese v 7zip

« kdy: 09. 04. 2017, 20:03:19 »

STALE NENI TADY MOC NAVRHU (JEN MUJ) NA ZADANI, JAKE JE NEJLEPSI NASTAVENI KOMPRESE V 7Z

Maly test pro lzma vs. lzma2.

Nastaveni bylo vzdy toto:
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=64m -ms=on JmenoArchivu.7z
7z a -t7z -m0=lzma2 -mx=9 -mfb=273 -md=64m -ms=on JmenoArchivu.7z

Data c.1 - textove soubory z daty.
Folders: 364
Files: 1272
Size:       482187948 B

Velikost lzma: 64143646 B
Velikost lzma2: 64158311 B

Data c.2 Linuxove skripty v ruznych verzich, hodne cyklu a pod. Data docela podobna.
Folders: 16
Files: 237
Size:       20059298 B

Velikost lzma: 624962 B
Velikost lzma2: 624273 B

Data c. 3 Linuxove skripty v ruznych verzich, hodne cyklu a pod. K tomu navic 2 datove soubory s cisly (real, integer), tyto stejne soubory na nekolika ruznych mistech. Opet dost podobnosti.

Folders: 24
Files: 535
Size:       236838685 B

Velikost lzma: 3184034 B
Velikost lzma2: 3170817 B

Data c. 4 - hodne excelovych souboru ve formatu do r. 2003. Excelove soubory jsou hodne podobne se stejnym formatem, data v nich se lisi. K tomu pod 10% odhaduji tvori samotne textove soubory s daty (cisla) - format TXT, CSV, DAT. Do cca. 2-3 MB, tedy cca 0,1% dat jsou nekomprimovatelne PNG obrazky (barevna hlobka 8 bit, uroven PNG komprese 9 - max). V nazvech souboru jsou mezery, hacky, carky, blbost z minulych let.

Folders: 213
Files: 6444
Size:       2370465554 B

Velikost lzma: 135076665 B
Velikost lzma2: 134751155 B

Data c. 5 - PNG obrazky, schematickeho typu. Barevna hloubka 24 bit, uroven png komprese 9 - maximalni.

Folders: 49
Files: 5867
Size:       634094047 B

Velikost lzma: 598956622 B
Velikost lzma2: 599022977 B

Tedy lzma2 je o neco lepsi vetsinou, radove setiny procenta Rozdil nikdy nepresahl 0,1%. U lzma2 procento dokonceni archivu i kontroly dat skokove pribyvalo, u lzma1 to bylo plynulejsi. Rychlost je vicemene stejna, mozna lzma2 je o neco rychlejsi. Procesorovy cas na slabem Pc byl delsi nez hodinu akorat u velkeho datoveho souboru (cca. 2,3 GB). CPU jeden blok naraz (a s tim okolo 720 MB RAM pri 64 MB slovniku) to vyuziva na 2 vlakna/jadra, pricemz vetsinou vyuziti je 110-195% normalizovano 1 vlakono = 100 %. paq8px vyuziva jedno vlakno jen, vetsinou k 100%, ten ale ted testovan nebyl (trochu to trva). Jak je to u lzma vs. lzma2 s chybovosti archivu, tod otazka. Ale oboji by melo byt OK a u obou je rozbaleni ci kontrola archivu podstatne rychlejsi nez komprese.

Rychlost na slabem PC je okolo 200-600 kB/s, pri paq8px cca 0,5-2 kB/s

282

Vývoj / Re:Zabránění kopírování obsahu WWW

« kdy: 19. 10. 2015, 14:43:36 »

O úplné zabránění kopírování a neprolomitelné ochrany se pokoušel kde kdo a neprolomitelné ochrany padli pár týdnů po vydání. 100 % účinnost neexistuje, kdo chce, ten si to ykopíruje, i kdyby si měl dát kameru před monitor (tato hláška je zdiskuye o ochraně kopírování filnů). Otázkou je jak moc je to složité a komu se do toho bude chtít. Již menší zespožitění spouatu stahovačů odradí.

Řešení věci z druhé stránky se probíralo tady http://forum.root.cz/index.php?topic=10541.0
A už i bez ochran je stažení některých webů obtížné - komplikovaná struktura odkazů, hodně souborův malém adresáři, dlouhé trvání.

Takže
-Mít víc linků co nikam nevedou a ještě lépe navzdájem propjených, dynamických html stránkek (se třemi parametry a každej 1000 možností, budou se vytvářet z malé databáze do 100 kB ale bude to až 1 000 000 000 malých souborů (to je jednotky až desítky, stovky TB dat, po 1 000 000 souborů to skoro každý stahovač stejně vzdá), všechny v jednom adresáři - to zatíží stroj stahovatele o mnoho víc než web server. Víc jak 100k-1M souborů v jednom adresáři je pro stahovače velká zátěž na CPU, disk i RAM. Zvedne to ti traffic webserveru. Pro lepší účinnost nemít na první pohled jasný tvar URL pro prázné stránky. A odkaz naně malý, aby byl co nejmíň viděl, ale stahovač ho načte. Podobně fungují např. i kalendáře s událostmi na webu.
Některí prázdné stránky se budou načítat 1-10 s, některé i přez 10 s, u správných stránek bych automatické zpomalení a na max. 1-2 s. To yvýší časovou náročnost pro stahovače.

-Nějaké to přesměrování, v tom se nevyznam.

-Složitý tvar url adres, tvořený ze statických html stránek - koukni na portal.chmi.cz. Bude to ale i zvýšená zátěž pro tvůj server a složitost i cena vytvoření vysoká, i pro koncové uživatele velká zátěž a pomalé odezvy. Podobně můžeš mít obrázek složený z částí Java Skriptem - výsledek stejný - obtížnost vysoká pro uživatele i web server.

-časové omezení - možnost přejít na další odkaz 1-10 s po předchozím requestu. Sledovat, zdali se requesty neopakujou s určitou časovou periodou (není celočíselná, ale reálné číslo). V případě detekce periody máš podezřelého. Podobně i véc jak 1000 requestů za den. Pozor IP adresa může skýtat víc uživatelů za natem, i tisíce, viz koleje.

-Průhledné GIFy či PNG, v pdf souborech nějaké vodoznaky či tak něco, cookies, kontrolní součty závislé na uživateli a IP, něco z toho můžeš použít.

-ROZHODNĚ uživatelská jména a hesla, https spojení.

-Např. Google paranoio, fotky z míst na mapě, 500 px má nějaké ochranz proti uložení - nedají se moc dobře automatizovat u Google paranoio dokonce ani klasickz uložit se mi nepodařilo.

-Možná i captcha, ale ne moc často (po 100-1000 requestech). Nějaká časká otázka s diaktitikou, ne nečitelké texty v  obrázku a pod.

-Varování o CopyRight + právní postihy v úvodu stránky.

Nic jiného mě teď nenapadá. Kopletní zabránění NENÍ MOŽNÉ. Ale zesložitění a tím i odrazení stahovačů jde.

283

Vývoj / Re:Jak vytvořit 1 000 000 položek

« kdy: 14. 09. 2015, 10:38:37 »

Oprava prvni vety - 1000 argumentu v cyklu je OK.Ale co vim, tak limit je prave cca 1 000 000, ne pocet argumentu ale velikost vyctu v promennych v pameti max. 1 MB ci tak neco. Tedy pokud max 1 polozka 20 znaku, max. 50 000.  Ten muj skript neni nahodny, ale ucel asi splnuje.

Jaky je to ucel ?
-Skartace staruch dat ?
-Kurveni disku ve firme nebo skole ?

284

Vývoj / Re:Jak vytvořit 1 000 000 položek

« kdy: 14. 09. 2015, 10:32:41 »

Pokut narves 1000 argumentu do 1 cyklu, muze to taky napsat "Argument list too long" a 1 000 000 souboru v jednom adresari je sranda, i 100 000 souboru.

Takto v Bashi ti vytvori dost souboru a slozek. Zadas cislo pocet a vytvori ti to pocet^2 zslozek a pocet^3 souboru, vsechny stejne. Jinak. min velisost souboru i velikost adresare je 4096 B obvykle, tedy jeden cluster. Limity na pocet souboru jsou ruzne, vetsinou milion az miliarda. Misto kde probehne utok je CestaDoTvehoAdreare , zadas bez posledniho lomitka.

Kód: [Vybrat]

#!/bin/bash

CestaDoTvehoAdreare="/tmp/neco"
pocet="1000"

for XXX in `seq -w ${pocet}` ; do
for YYY in `seq -w ${pocet}` ; do
mkdir -p ${CestaDoTvehoAdreare}/${XXX}/${XXX}${YYY}/
for ZZZ in `seq -w ${pocet}` ; do
echo "Drsnej skript to je" >> ${CestaDoTvehoAdreare}/${XXX}/${XXX}${YYY}/${XXX}${YYY}${ZZZ}.txt
done
done
done

Jinak pokud chces skartovat obsah disku, tak az cca 11x prepsane jde obnovit. Proto meni moddifikace skriptu o cyklus vic:

Bacha je tu rm -fr *, ujisti se zda dany adresar, ktery se iotevre pred spustenim priklazu existuje, jinak to bude mazat jinde.
Mysli i na cas behu skriptu.

Kód: [Vybrat]

#!/bin/bash

CestaDoTvehoAdreare="/tmp"
pocet="1000"
PocetCyklu="50"

for Cykly in `seq ${PocetCyklu}` ; do
for XXX in `seq -w ${pocet}` ; do
for YYY in `seq -w ${pocet}` ; do
mkdir -p ${CestaDoTvehoAdreare}/${XXX}/${XXX}${YYY}/
for ZZZ in `seq -w ${pocet}` ; do
echo "Drsnej skript to je" >> ${CestaDoTvehoAdreare}/${XXX}/${XXX}${YYY}/${XXX}${YYY}${ZZZ}.txt
done
done
done
cd ${CestaDoTvehoAdreare}/
rm -fr *
done ## cykly


285

Software / Re:Program pro stažení celého webu

« kdy: 31. 07. 2015, 10:32:18 »

Odkaz

http://uloz.to/x89biSX2/web-stary-astromat-cz-7z