Jednoduché formáty souborů (NetPBM, Dot, PCAP…)

5.4.2021 19:15 | Přečteno: 3604× | Linux | | poslední úprava: 3.5.2021 02:55

Představíme si formáty souborů vhodné pro rychlé bastlení - zpracování obrazu, ladění datových struktur a síťovou komunikaci. Hlavní zajímavostí je jejich čtení a zápis pomocí ad-hoc skriptů bez použití externích knihoven.

Jedná se o přepis mé přednášky ze Smrště 2018. Z různých ostatních přednášek existují záznamy, třeba se vám budou líbit.

Bitmapový formát Netpbm

Formát obrázků Netpbm vypadá takto:

P5
# libovolné množství komentářů
# každá řádka uvozena vězením
šířka výška
255
surová bitmapová data

Číslo za P na prvním řádku udává formát bitmapových dat, číslo před daty udává rozsah (barevnou hloubku), prakticky vždy chcete 255 (1 bajt na pixel, resp. na barevnou složku u barevného obrázku). Zajímavé formáty bitmapových dat jsou:

• P2 - černobílý obrázek, bitmapová data jsou čísla v ASCII (0 - černá, 255 - bílá) oddělená libovolným množstvím bílých znaků.
• P3 - barevný obrázek, bitmapová data jsou čísla v ASCII oddělená libovolným množstvím bílých znaků, postupně RGB složky jednotlivých pixelů
• P5 - černobílý obrázek, bitmapová data jsou surové bajty
• P6 - barevný obrázek, bitmapová data jsou surové bajty

Černobílé varianty se označují PGM (graymap), barevné PPM (pixmap).

Čtení

ASCII varianty se získají pomocí convert vstupní.png -compress none výstup.pgm (nebo ppm) a hodí se na grepování. Pár příkladů ze života:

• Varování před bouřkou/deštěm: pokud se blíží déšť, chci být probuzen, abych šel uklidit prádlo sušící se na zahradě. Případně máme experiment, který se má spustit, když jde v okolí bouřka. Stáhneme aktuální nowcastingový obrázek radaru (wget), vyřízneme okolí místa, které nás zajímá (convert ... -crop 100x100+10+10 ...), ve výsledném souboru grepneme barvu odpovídající dešti, a pomocí Odorik API mi zazvoní telefon (opět wget). To celé na čtyřech řádcích shellu. A to je prý o varování před deštěm zájem jako o prémiovou službu .

• Spočítání, kolik vody proteklo při povodni. Máme graf průtoku

  

  a chceme sečíst pixely s nějakou barvou. (přičemž barvu můžeme zjistit třeba tak, že ji v GIMPu nabereme kapátkem)

  $ convert VLCH.gif -crop 1000x131+0+330 -compress none out.pgm
  $ cat out.pgm | tr " " "\n" | grep 129 | wc -l
  13734

  Škoda, že mě tohle nenapadlo, když jsem psal odkazovaný komentář.

• Nechci, aby telefon zvonil, pokud jsem doma (pozná se podle WiFi SSID) a spím (což se pozná podle toho, že je tma). Jak poznat, že je tma?

  # grabneme jeden snímek z webkamery
  $ mplayer tv:// -tv device=/dev/video0 -vo jpeg -frames 1
  # zkonvertujeme ho na úžasný formát PGM
  $ convert 00000001.jpg -compress none out.pgm
  # spočítáme počet pixelů, které mají jas větší než 100
  $ cat out.pgm | tr " " "\n" | grep "^...$"|wc -l

  (a tohle funguje i pokud zalepíte kameru samolepkou, pokud je alespoň trochu průsvitná)

• Laserová gravírovačka ze skeneru a jehličkové tiskárny a laseru z projektoru. Shellový skript čte po řádcích černobílý obrázek a generuje příkazy „krok; zapnout laser; krok; vypnout laser“ podle toho, jestli je pixel černý nebo bílý. Tohle se dá zbastlit za pět minut.

       

  hele, byl rok 2011 a byl jsem lama. Co jste vy dělali když vám bylo 18?

Jediné trochu mrzuté je, že pokud chcete grepovat opravdu konkrétní RGB barvu, tak musíte sestavit regexp, který to bere po správně zarovnaných trojicích. Tohle by asi mohlo fungovat (rozdělí pixely na samostatné řádky):

$ cat out.ppm | sed -re "s/([0-9]+ [0-9]+ [0-9]+)/\1\n/g" | sed -re "s/^ //"

Zápis

Co se zápisu týče, tak tam se asi nejvíc hodí binární formáty (P5, P6), pro takové ty situace „mám v paměti pole a potřebuju ho vyklopit do souboru“. Jednoduše otevřeme soubor, vypíšeme do něj ty tři řádky (P5, velikost, 255) a pak do něj vyklopíme to pole. Můžeme přidat komentář.

Komprese

Pokud to dává smysl (tj. data mají nějakou strukturu, takže to jde komprimovat), je nejlepší soubor prohnat bzipem. Mnoho nástrojů (např. GIMP, ImageMagick…) ho i pak rozpozná a automaticky dekomprimuje a otevře. Kompresní poměr je podobný, někdy i lepší (!) než u PNG, které je na obrázky přímo specializované. Prý je to proto, že ačkoli má PNG lepší kódování (nebere to tupě po řádkách, ale umí se odvolat na předchozí řádky), tak má jako poslední krok obyčejné DEFLATE, které je podstatně horší než bzip2.

Zajímavé je, že některé obrázky se podstatně lépe komprimují otočené o 90° (resp. transponované) - pokud vám tedy záleží na účinnosti a rychlosti (!) komprese, stojí za to podívat se, jestli váš typický obrázek nemá například ve sloupcích podstatně podobnější data než v řádcích, a případně ho otočit. Třeba data z radaru se násobně líp komprimují podle azimutu (protože věci blízko u sebe jsou si samozřejmě velmi podobné) než podle vzdálenosti (kdy kompresor dostane celou scanline pokrývající stovky kilometrů a co pak s tím má jako dělat).

Farbfeld

Existuje ještě jednodušší formát farbfeld, který má pouze velikost a pak natvrdo RGBA 4*16bit hodnoty. To mi už přijde příliš omezené a navíc je to 16bit big endian, takže se s tím blbě pracuje a je to velké. Také není tolik podporovaný, PGM/PPM otevřete v Eye of GNOME, v GIMPu, v lecčems.

Video

Stejně jako PPM (syrové RGB pole) můžeme zpracovávat i video. ffmpeg podporuje formát rgb24 a raw kontejner. Nemá to vůbec žádnou hlavičku, takže rozlišení musíme předat ručně (a když se dám blbě, tak se rozbije synchronizace) a pak už čteme framy. Tady je třeba oneliner co vezme první frame z videa velkého 640x480 a uloží ho jako PPM .

$ (echo -ne "P6\n640 480\n255\n"; ffmpeg -i test.mkv -pix_fmt rgb24 -f rawvideo -y - | head -c $(( 640 * 480 * 3 )) ) > soubor.ppm

A takhle se zase ze souboru zpátky udělá video:

$ (while true; do tail -c $(( 640 * 480 * 3 )) soubor.ppm ; done) | ffmpeg -f rawvideo -pix_fmt rgb24 -s 640x480 -i - -y out.mkv

Audio

aplay žere surové samply, je vhodné mu říct formát a samplerate. Geiger counter v bashi:

$ while true; do if [ $(( $RANDOM % 200 )) -eq 1 ]; then echo -n "~"; else echo -n "                "; fi; done | aplay -r 16000 -f U8

(tilda a mezera jsou napsatelné znaky s nejvzdálenějším ASCII kódem)

WAV soubory jsou hlavička a pak následují samply. Pokud víte, v jakém jsou formátu (nejběžnější je signed int16 little endian), můžete začátek souboru přeskočit a číst rovnou ty samply.

Dot: grafy

Zejména pro ladění složitých datových struktur s hromadou ukazatelů se hodí dot. Vytvoříme následující soubor:

digraph{
a->b;
b->c;
c->d;
c->a;
}

a spustíme dot -T png file.dot > file.png.

Dot automaticky rozhodí vrcholy aby se hrany nějak zásadně nekřížily a natahá definované šipky. Samozřejmě se to dá všechno různě formátovat, více viz Graphviz.

Dot jsem objevil náhodou při dělání úkolu do velmi drsného a poučného předmětu Datové struktury 1 a nevím, jak bych to bez něj odladil. Také jsem to použil při řešení jednoho CTF, kde byly soubory, které se navzájem na sebe různě odkazovaly. A někteří ISP to prý používají pro generování mapy své sítě.

PCAP: síť

pcap je formát, ve kterém se ukládají záznamy síťového provozu - používá ho například tcpdump a Wireshark (ten už tedy používá vylepšení pcapng, ale pcap samozřejmě stále umí). Je také překvapivě jednoduchý, na začátku je nějaká celkem nezajímavá hlavička (pcap_hdr_t) a pak je vždycky hlavička paketu (pcaprec_hdr_t, obsahuje jeho délku) a následuje přímo ten paket. Pakety takhle můžete snadno číst (osobně jsem třeba takhle implementoval mergování paketů z několika zdrojů do jednoho pcap souboru) i generovat (normálně si zkopírujte paket a nahrazujte v něm data, a na checksum se vykašlete, různé tsharky a spol. to sežerou i když nesedí).

       

Komentáře

[z_sk]

Na grafy (ak user klikatko) napríklad program Dia.

[Max]

Nevím, nevím. Hele, používal jsem to dřív a bylo to peklo. Pak jsem přešel na MS Visio (kvůli práci a kompatibilitě s ostatními firmami, se kterými něco řešíme) a nedá se to srovnat. Ve světě OSS Dia silně zaspala. 100x lepší je yEd.
Nicméně je možné, že Dia křivdím a za ty roku, co jsem to opustil, se zlepšili.
Nicméně kromě Dia a yEd je dost použitelný i Draw v Libreoffice.
Zdar Max

[Gilhad]

Koukal jsem na ten yED, ale nejak nemuzu najit pod jakou je licenci ...

[Max]

Custom:

yEd Software License Agreement

Version 1.2
This is a legal agreement ("this Agreement") between yWorks GmbH ("yWorks") and the licensee ("the Licensee").
yWorks licenses the yEd Software ("the Software") only if all the following terms are accepted by the Licensee.
The Software includes the yEd byte code executable and any files and documents associated with it.

By installing the Software, the Licensee is indicating that he/she has read and understands this Agreement and agrees to be bound by its terms and conditions.
If this Agreement is unacceptable to the Licensee, the Licensee must destroy any copies of the Software in the Licensee's possession immediately.

1. LICENSE CONDITIONS
The Licensee is granted a non-exclusive and non-transferable right to install one copy of the Software and use it as an application.
The Software may not be used as part of an automated process.
The Licensee may not reverse engineer, disassemble, decompile, or unjar the Software, or otherwise attempt to derive the source code of the Software.

The Licensee acknowledges that Software furnished hereunder is under test and may be defective.
No claims whatsoever can be made on yWorks based on any expectation about the Software.

2. TERM, TERMINATION AND SURVIVAL
The Licensee may terminate this Agreement at any time by destroying all copies of the Software in possession.
If the Licensee fails to comply with any term of this Agreement, this Agreement is terminated and the Licensee has no further right to use the Software.
On termination, the Licensee shall have no claim on or arising from the Software. The Software and any copies shall be destroyed.

3. NO WARRANTY
The Software is licensed to the Licensee on an "AS IS" basis. The Licensee is solely responsible for determining the suitability of the Software and accepts full responsibility and risks associated with the use of the Software.

4. MAINTENANCE AND SUPPORT
yWorks is not required to provide maintenance or support to the Licensee.

5. LIMITATION OF LIABILITY
In no event will yWorks be liable for any damages, including but not limited to any loss of revenue, profit, or data, however caused, directly or indirectly, by the Software or by this Agreement.

6. DISTRIBUTION
No distribution is to be made of the Software by the Licensee. The Licensee may make one copy of the Software for backup purpose only.

7. AVAILABILITY
The Software is not available to those not permitted by law to have access to the Software.

8. INSERTION OF MARKER
The Software may insert some markers into any output files to identify that the files are generated by the Software. yWorks bears no responsibility for any damages arising.

9. MISCELLANEOUS
This agreement is made and shall be construed in accordance with the laws of Germany.

---------------------------------------------------------------------------

THIRD-PARTY SOFTWARE AND LICENSES
This Software uses the Batik SVG Toolkit, Apache XMLBeans, Apache POI, and FreeHEP VectorGraphics library which are licensed under The Apache Software License (http://www.apache.org/licenses/).
This Software uses the JIDE Docking Framework and the JIDE Action Framework licensed from JIDE Software (http://www.jidesoft.com).
This Software uses icons licensed from Incors GmbH (http://www.incors.com).
This Software includes a parser generated with ANTLR v3, a Swing LnF created by JGoodies, and the TwelveMonkeys library. The BSD License applies to them (http://www.opensource.org/licenses/bsd-license.html).
The Swing LnF created by JGoodies uses some icons from the Tango project (http://www.tango-project.org/) licensed under the Creative Commons Attribution Share-Alike license (http://creativecommons.org/licenses/by-sa/2.5/). 
This Software uses the svg-viewer rendering engine (http://code.google.com/p/svg-viewer/). The MIT License applies to it (http://www.opensource.org/licenses/mit-license.php).
This Software uses the JavaHelp System v2.0_02 (https://javahelp.dev.java.net/). The Sun Microsystems, Inc. Binary Code License Agreement with JavaHelp Version 2.0 Supplemental License Terms applies to it.
The installer for this Software may contain a Java Runtime Environment (JRE). The Oracle Binary Code License Agreement for the Java SE Platform Products applies to it (http://www.oracle.com/technetwork/java/javase/terms/license/).

Zdar Max

[Gilhad]

Aha, tak nic, zustanu u dia i nadale ...

[Bedňa]

MS Visio? To fakt Maxi?

[Ruža Becelin]

PlantUML a Diagrams (drawio). Na Dia jsem zacinal, ale zamrzla v 199x, bohuzel.

[User682]

zdravim,

dia jsem zkousel a tak nejak na uplne zakladni veci pred hodne par roky stacila.

Pak jsem nasel yEd a to je na nejake kresleni postacujici, pokud clovek nechce nejake lehce slozitelsi diagramy.

Postupne jsem dosel k Visual Paradigm (placeny nastroj, ale je i snad nejake komunity edition) a je to, co jsem shanel. Na dost veci, co z architektury delam, se primo nabizi delat nejake UML a je to navic i srozumitelnejsi okoli. Nebo se to da casem prepouzit.

Posledni 2 roky programuju vcelku dost grafove algoritmy (teorie grafu) a hodne toho delam z tohoto oboru na papire+barevne fixy, kdyz mi to hlava nebere, obcas se divim, ze na to nevezmu nejaky soft. UML a CASE nastroje spise pouzivam na nejake navrhovani vetsich celku nez na reseni konkretnich algoritmu.

gf

[Mayhem Weltende]

Jak se ma linuxsoft? Pozvanky na pivo ani ohlednuti ze neuspesnym rokem uz nejak nevychazeji.

Nechces mi to prodat?

[_]

muzu ti prodat nejake stribrne pribory se slepici, nasel jsem je v lese

[Heron]

Dot je super. Jednak se to snadno píše ručně, vytvořit si graf závislostí něčeho na něčem (libovolně čeho) je hned. Automatické generování ani nezmiňuju, používá se to i na místech, kde bych to nečekal (systemd-analyze). Sám generuju graf DFA z definice v jednom programu pro kontrolu správnosti zadaných údajů podle jednoduché gramatiky. Jen je škoda, že generování obrázku (graphviz) nenabízí příliš mnoho možností, jak poradit umístění některých nodů - zkoušel jsem to používat pro mapu sítě a není to ono.

Prý je to proto, že ačkoli má PNG lepší kódování (nebere to tupě po řádkách, ale umí se odvolat na předchozí řádky), tak má jako poslední krok obyčejné DEFLATE, které je podstatně horší než bzip2.

Ano, i farbfeld (což je můj oblíbený archivní formát typu jednodušeji už to nejde) prohnaný přes LZMA je menší než i dobře optimalizovaný png. Což je zvláštní, zatímco optimalizace png pro nejlepší kombinace filtrů trvá fakt dlouho, tak obecná komprimace bez znalosti formátu přináší lepší výsledky o mnoho rychleji.

[jednoduche_formaty_souboru]

možnost zpracování bitmapy skriptem se mi líbí, určitě pro to najdu využití, ale třeba v uvedeném příkladu s detekcí deště, jednoduše obrázek předpovědi srážek v nějaké oblasti nezískám, mapy radaru se generují dynamicky, wget by na tohle asi nestačil...

[Jendа]

wget https://www.chmi.cz/files/portal/docs/meteo/rad/inca-cz/data/czrad-z_max3d/pacz2gmaps3.z_max3d.`date -u "+%Y%m%d.%H%M" -d "10 minutes ago"`.0.png

? (s tím že by to chtělo zkusit poslední dva - někdy tam je obrázek už za 3 minuty, někdy to trvá 15)

[jednoduche_formaty_souboru]

dík za odkaz na data, tohle jsem nemohl najít

[Jendа]

Otevřel jsem tu odkazovanou stránku, dal jsem Ctrl+I (Page info), "Images", a tam to je.

[Gréta]

jj sou to supr fígle :D ;D

[Tom.š Ze.le.in]

Co jsem ocenil na graphviz formátu až nedávno jsou návazné filtry. Je docela fajn je možnost automaticky generovat graf relativně "tupě", a pak ho podle potřeby "stylovat" pro různé účely pomocí gvpr - obarvit podle typu, nechat jen "zajímavé" texty nebo určitý typ vrcholů, nebo - po profiltrování přes dijkstra - jen nody blízké vybranému a podobně.

Například se takhle dá udělat "proklikávací" graf - z velkého grafu (typicky nečitelného při zobrazení) se zobrazí nody v nějaké vzdálenosti od vybraného, a po kliknutí na jeden z nich zobrazí okolí vedle (a třeba po dvojkliku se skočí na URL v node, který říká o node víc).