Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 141 (pdf) a HackSpace 78 (pdf).
Byla vydána verze 2.0.0 programovacího jazyka Kotlin (Wikipedie, GitHub). Oficiálně bude představena ve čtvrtek na konferenci KotlinConf 2024 v Kodani. Livestream bude možné sledovat na YouTube.
Byla vydána nová major verze 27.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Byla vydána nová verze 1.8.0 svobodného multiplatformního softwaru pro konverzi video formátů HandBrake (Wikipedie). Přehled novinek v poznámkách k vydání na GitHubu. Instalovat lze také z Flathubu.
Microsoft představil nové označení počítačů Copilot+. Dle oznámení se jedná se o počítače poskytující funkce umělé inteligence. Vedle CPU a GPU mají také NPU (Neural Processing Unit). Uvnitř představených Copilot+ notebooků běží ARM čipy Qualcomm Snapdragon X Elite nebo X Plus.
Příspěvek na blogu Codean Labs rozebírá zranitelnost CVE-2024-4367 v PDF.js, tj. mj. prohlížeči PDF souborů ve Firefoxu. Při otevření útočníkem připraveného pdf souboru může být spuštěn libovolný kód v JavaScriptu. Vyřešeno ve Firefoxu 126.
Lazygit byl vydán ve verzi 0.42.0. Jedná se o TUI (Text User Interface) nadstavbu nad gitem.
K open source herní konzole Picopad přibyla (𝕏) vylepšená verze Picopad Pro s větším displejem, lepšími tlačítky a větší baterii. Na YouTube lze zhlédnout přednášku Picopad - open source herní konzole z LinuxDays 2023.
Pátý díl nepravidelného seriálu o psaní video ovladačů pro Linux. Pokud jste ještě nečetli první díl, možná by stálo zato začít tam.
Než může aplikace začít pracovat s video zařízením, musí se s ovladačem dohodnout na tom, jak budou video data formátována. Takové dohadování může být docela komplikovaná záležitost, protože 1) podpora formátů v různých typech video hardwaru se dost výrazně liší a 2) provádění převodu formátů v jádře není vítáno. Aplikace tedy musí zjistit, které formáty hardware podporuje, a nastavit prostředí tak, aby to všem zúčastněným vyhovovalo. Tento článek se bude zabývat základy popisu formátů; další díl probere API implementované V4L2 ovladači pro dohadování o formátech s aplikacemi.
Prostor barev [colorspace] je v podstatě koordinační systém pro popis barev. Specifikace V4L2 jich popisuje několik, ale doopravdy používány jsou jen dva:
Kromě toho pokrývá tento barevný prostor i YUV a YCbCr. Toto znázornění vychází z potřeby mít možnost zobrazovat barevný televizní signál na monochromatických televizích. Takže hodnota Y (neboli "svítivost" [luminance]) je hodnota jasu [brightness]; když je zobrazena samostatně, dostaneme obraz v odstínech šedi. Hodnoty "chrominance" [barevný rozdíl] U a V (neboli Cb a Cr) popisují modré a červené části barvy; zelenou lze odvodit odečtením těchto částí od svítivosti. Převod mezi YUV a RGB však není tak docela prostý; na výběr je z několika vzorců.
YUV a YCbCr nejsou přesně totéž, i když se ty termíny často používají ve stejném významu.
Existuje docela dost dalších prostorů barev; většinou jde o varianty standardů souvisejících s televizí. Kompletní seznam najdete ve specifikaci V4L2.
Jak jsme si řekli, hodnoty pixelů jsou vyjadřovány n-ticemi, které obyčejně obsahují RGB nebo YUV hodnoty. Pro organizaci těchto n-tic do obrazu existují dvě nejčastěji používané metody:
Packed formáty se možná používají trochu častěji, především ve spojení s RGB, ale oba druhy lze hardwarem generovat a aplikace je mohou vyžadovat. Pokud video zařízení podporuje jak packed, tak planar formáty, ovladač by je měl uživatelskému prostoru nabízet oba.
Barevné formáty jsou v V4L2 API popsány pomocí mechanismu "fourcc" kódů. Tyto kódy jsou 32bitové hodnoty generované ze čtyř ASCII znaků. Lze s nimi tedy lehce manipulovat a jsou snadno čitelné. Když například vidíte kód barevného formátu 'RGB4', není nutné vyhledávat význam v tabulkách.
Kódy fourcc jsou využívány v mnoha různých případech, z nichž některé jsou starší než Linux. MPlayer je používá interně. Fourcc však označuje pouze mechanismus a neříká nic o tom, jaké kódy jsou vlastně používány - MPlayer má překládací funkci pro převod mezi fourcc kódy a těmi, které používá V4L2.
V popisech formátů (níže) jsou bajty vždy řazeny podle paměti - na little-endian stroji jsou nejméně významné bajty první. Nejméně významný bit každého bajtu je vpravo; u každého pole barev je nejsvětlejší odstín nejvýznamnější.
Název | fourcc | Byte 0 | Byte 1 | Byte 2 | Byte 3 | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
V4L2_PIX_FORMAT_RGB332 | RGB1 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB444 | R444 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB555 | RGB0 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB565 | RGBP | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB555X | RGBQ | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB565X | RGBR | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_BGR24 | BGR3 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB24 | RGB3 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_BGR32 | BGR4 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB32 | RGB4 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_SBGGR8 | BA81 | ||||||||||||||||||||||||||||||||||||
Když jsou použity formáty s prázdným místem (v tabulce zobrazena jako šedá políčka), mohou to místo aplikace využít pro alfa hodnotu (průhlednost).
Jedná se o "Bayer" formát, který je obvykle dost blízko opravdovým datům ze senzorů většiny kamer. Zelené hodnoty jsou pro každý pixel, ale modré a červené jen pro každý druhý. V podstatě jde o to, že zelená nese důležitější informace o intenzitě, přičemž červená a modrá jsou - tam, kde chybějí - přes pixely interpolovány. Podobné to bude u YUV formátů.
Nejprve packed YUV formáty. Klíč pro čtení této tabulky:
= Y (intenzita) |
= U (Cb) |
= V (Cr) |
Název | fourcc | Byte 0 | Byte 1 | Byte 2 | Byte 3 | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
V4L2_PIX_FORMAT_GREY | GREY | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_YUYV | YUYV | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_UYVY | UYVY | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_Y41P | Y41P | ||||||||||||||||||||||||||||||||||||
Používá se i několik planar YUV formátů. Nemá cenu je všechny vykreslovat - vystačíme si s jedním příkladem. Běžně používaný formát "YUV 4:2:2" (V4L2_PIX_FMT_YUV422, fourcc 422P) využívá tři samostatná pole. Obrázek 4x4 by byl znázorněn takto:
Y plane: | ||||||||||||||||||||||||||||||||||||
U plane: | ||||||||||||||||||||||||||||||||||||
V plane: | ||||||||||||||||||||||||||||||||||||
Stejně jako u formátu Bayer i YUV 4:2:2 má jednu hodnotu U a jednu hodnotu V na každou druhou hodnotu Y; zobrazení obrázku vyžaduje interpolaci chybějících hodnot. Ostatní planar YUV formáty jsou:
Existuje ještě pár dalších YUV formátů, ale ty se používají jen zřídka; vizte kompletní seznam.
Dva další formáty, které se mohou hodit pro některé ovladače:
Kromě toho jsou ještě další formáty, některé proprietární; seznam opět součástí specifikace.
Když už formátům barev rozumíme, můžeme se podívat na to, jak V4L2 API popisuje formáty obrazu obecně. Hlavní strukturou je struct v4l2_pix_format (definována v <linux/videodev2.h>), která obsahuje tato pole:
Dohromady tyto parametry poměrně uceleně popisují buffer video dat. Aplikace může vyplnit strukturu v4l2_pix_format a vyžadovat v podstatě jakýkoliv formát, jaký si vývojář dokáže vymyslet. Na straně ovladače však musí být omezení na formáty, se kterými hardware umí pracovat. Takže každá V4L2 aplikace s ovladačem vyjednává ve snaze najít formát obrazu, který by byl jak podporovaný hardwarem, tak vhodný pro potřeby aplikace. V dalším díle se podíváme na to, jak toto vyjednávání vypadá z pohledu ovladače.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: