Vlákno názorů k článku
Evropská komise bude regulovat externí zdroje a nabíječky od roku 2028 od kamui - 12 V zdroje s 5.5/2.1 mm jackem fungují...

Co by takový další standard přinesl těm laikům? Byl by to další druh kabelů a konektorů navíc k usb, které už stejně mají. A my sice víme, jak je usb složité, ale laik to řešit nemusí. Pro něj je to černá skříňka.
No a výrobce to vlastně taky řešit nemusí. Pro něj je to černá skříňka s pár vývody za pár drobných. :)

Pro něj je to černá skříňka... která náhodně funguje a nefunguje a on musí vyzkoušet X různých kabelů a nabíječek. S některými kabely mu bude fungovat nabíjení, s jinými zase rychlé přenosy dat, jindy to bude nespolehlivé, zařízení se připojí, počítač ho identifikuje a vzápětí se zase odpojí nebo se to rozpadne ve chvíli, kdy začne přenášet soubory.

Ono každé USB je poměrně složité (řádově složitější než třeba sériový port), ale do verze 2.0 to aspoň jakž takž fungovalo jako jednotný standard. Od 3.0 nabízí ještě rychlejší přenosy a více výkonu a různé zajímavé funkce, ale je už tak roztříštěný, že i když to navenek vypadá pořád jako stejný port, reálně je to spíš několik vzájemně nekompatibilních rozhraní. Z formátu TIFF si lidi kdysi dělali legraci, že je to „Thousands of Incompatible File Formats“. Bohužel mi přijde, že USB se dostává do podobného stavu.

P.S. Nechci, aby to vypadalo, že nemám rád USB. Ve skutečnosti tu mám rozečtenou knihu USB Complete a i nad tím něco málo vyvíjím, ale když do toho trochu pronikneš, tak víš, že situace není tak růžová, jak se snaží líčit marketing.

Což tedy nemění nic na tom, že pro připojování periferií prakticky jinou možnost než USB nemáme (maximálně tak ještě Ethernet nebo občas nějaký ten bezdrát). Jen se mi příčí, když se to někdo snaží protežovat a shora diktovat lidem. Pokud je to skutečně nejmenší zlo, tak to průmysl bude používat tak jako tak. Ale byla by škoda zašlapat do země potenciálně lepší řešení, jen kvůli výmyslům byrokratů.

On se to nikdo lidem shora nutit nesnaží. Výrobci používají USB o své vlastní vůli, jenže je v tom takový nepořádek, že se to prostě občas musí zregulovat. Ještě že máme USB-C, konečně jeden konektor stejný na obou stranách.

Bohuzial bez toho "protezovania" to niekedy nejde.
Prumysl mal cas a nevyriesil to.
Nic nieje nemenne ak niekto vymysli nieco lepsie, tak ani EU nieje taka aby nezmenila danu regulaciu.
V case zavedenia nic lepsie(mensie zlo) sme nemali.

Seriovy port je jednoduchsi ale robit s nim bolo utrpenie a bolo to uzivatelsky neprivetive.
USB je na druhej strane jednoduche na pouzivanie ale interne zlozitejsie.

Z formátu TIFF si lidi kdysi dělali legraci, že je to „Thousands of Incompatible File Formats“.

To mi připomnělo: NTSC - Not The Same Color :-D

Ona je stejně sranda, kolik formátů lidé potřebují vymyslet. Na obrázky je asi nejlepší FarbFeld (Suckless project), kde je hlavička, rozměry obrázků a podle RGBA64 (16b na kanál) a je to. V Golangu je přímo typ Color.RGBA64, takže se uloží jen pole a přidá k němu hlavička.

Já mám všechno v RAWu z foťáku a potom v PNG optimalizovaném pomocí pngcrush a s tím si některé prohlížeče také neporadí. FarbFeld je easy, implementaci si napíšu za pět minut, kompresi to nemá, takže použiju LZMA2 a je to menší než PNG. PNG má i CRC, což je vlastně k ničemu, protože dneska k tomu přidám SHA3 a je to zcela moderní formát i pro ten raw.

> Ona je stejně sranda, kolik formátů lidé potřebují vymyslet. Na obrázky je asi nejlepší FarbFeld (Suckless project), kde je hlavička, rozměry obrázků a podle RGBA64 (16b na kanál) a je to. V Golangu je přímo typ Color.RGBA64, takže se uloží jen pole a přidá k němu hlavička.

Hmmm, tak se na to koukneme. V hlavičce jsou rozměry a jinak nic. Navíc big endian, takže sranda navíc. Co barevný prostor? Ok, nic povinného, jen by to mělo být srgb bez premultiplied alphy. Zatímco Color.RGBA64 má premultiplied alphu a dost bych se divil, kdyby to byl big endian.

Na dočasná data při jednomužném používání asi použitelné. I když nezdokumentovaný dump do souboru se dá udělat i jednodušeji. Cokoliv složitějšího dopadne špatně.

Do RGBA64 sa zmestí Rec 2020... takže s sRGB by som si teda nebol až tak istý.

Takto dopadá návrh, keď si niekto myslí, že obrázok je len dvojrozmerné pole pixelov a pixely znamenajú všade to isté.

Jo jo, premultiplied alpha a sRGB si moc nerozumí. Jde to, ale dře to. Tenhle dílek skládačky mi ušel. On i ten zbytek stačí až na půdu. :)

Koukám, že když se chce, tak se chyba dá najít na čemkoliv (alespoň tedy pro diskusi). :-D Pokud mě znalosti neklamou, tak zatím není žádný foťák, který by uměl více než 16b na kanál, takže se to tam vejde v podstatě jako RAW. Co si s tím udělá zobrazovací program je čistě jeho věc.

Až na to, že ten formát není pro RAW určený. Dokumentace píše jen o srgb. Nikde se tam ani nepíše, jak tam nasypat data před debayerizací.
Použil jste formát, jehož dokumentace je skoro kratší než url, co k ní vede. A ještě jste z toho velký kus odignoroval. Ten zbytek je dobrý akorát ke zmatení nepřítele.
Nechápu, proč se s tím vůbec obtěžujete. Ten formát neumí prakticky nic a ještě jste si ho musel ohnout aby šel použít. Data ve formátu, který musím sám popsat, se dá nasypat do souboru jednodušeji napřímo. Bez nutností ohýbání nějaké třetí party.

Já se s tím neobtěžuju. Diskutuji v diskusi, kde si někdo dělá legraci z TIFF a já jsem uvedl negativní zkušenost s PNG, které opravdu ne každý prohlížeč umí správně dekódovat, tak jsem uvedl formát, který je tak jednoduchý, že dekodér napíše i středoškolák jako maturitní úlohu.

A ano, každý si napíše vlastní formát, to není vůbec těžké, ale otázkou je, proč nemáme jeden formát prostě pro všechno. Což by šlo udělat snadno, 64b na kanál, třeba bez komprese (tu ať si každý vybere svou) a uloží se tam jak RAW, tak i něco pro web.

Co obecně vnímám jako velký problém z minulosti je to, že si každý vytvořil formát dle HW. Tohle já nedělám, vše mám jako int64 (bigserial, bigint v PostgreSQL) a nemám žádný problém. A od té doby, co to takto dělám, tak slyším pouze narážky typu: "to v receptu bude opravdu 2^64 ingrediencí?", jenže na rozdíl od nich potom nemusím měnit int8 na int32 apod. Můj návod je: "použij to největší co existuje a nebudeš mít problém".

> A ano, každý si napíše vlastní formát, to není vůbec těžké, ale otázkou je, proč nemáme jeden formát prostě pro všechno. Což by šlo udělat snadno, 64b na kanál, třeba bez komprese (tu ať si každý vybere svou) a uloží se tam jak RAW, tak i něco pro web.

Protože tam třeba chybí informace, co je v těch 64b na kanál? Máme různé RGB prostory, protože žádné rgb neumí reprezentovat všechny viditelné barvy. Naše oči nefungujou tak jednoduše. Takže jeden formát těch kanálů pro všechny ůčely stačit určitě nebude.

Si to predstavujete ako hurvinek valku. V tom formate chyba kopec informacii, ako data interpretovat, takze by bol treba nejaky sidecar file, ktory by chybajuce metadata doplnil. Ako tu uz padlo, aka gamma? linear rgb alebo srgb? Ake transferove krivky? (dovod, preco rovnaky raster vyzera inak na tv ako na pc, ked sa len vydumpuje do framebufferu). Alebo co tak este vacsi gamut, adobe rgb, dci-p3 alebo rec2020? A co ked nejde vobec o rgb? Co ked data su yuv? Ktory yuv? Lab? Organizacia pixelov je planar alebo packed? Raw? Ktory?

Dalej mame oborove metadata. Napriklad ortofoto su georeferencovane, aby existovala informacia, aku cast uzemia snimok zabera a bolo mozne snimok umiestnit na mapu inak ako rucne. To znemana nielen informacie o suradniciach, ale aj o suradnicovom systeme.

No a nakoniec aj kompresia: nie vsade je mozne dovolit si mat nekomprimovane rastre. Faxy (ok, dnes uz historia) alebo kopirky (to este historia nie je) si to komprimuju svojim specifickym algoritmom, aby sa im to pomestilo s ohladom na ich zdroje. Na 600 alebo 1200dpi b/w raster je uplna blbost pouzivat rgba64.

Takze tu niekde je dovod, preco tiff vyzera tak ako vyzera. Tiff ma tieto veci relativne standardizovane, aj ked je jasne, ze nie kazda aplikacia vie interpretovat kazde rozsirenie. V jednoduchsich formatoch si kazda aplikacia musi heuristicky domysliet, ako ich vobec zobrazit. Na to by sme mali rozlicne sidecars, kde kazdy pes jina ves.

Alebo graficke api, ako opengl, directx, vulkan, metal: tiez venuju cast api strukturam, ktore popisuju, ako presne je organizovany buffer s datami. Je to otravna cast prace s nimi, ale bohuzial potrebna.

takze by bol treba nejaky sidecar file

Jenže tohle má každý editor RAW souborů. Pokud sáhnu na RAW, tak si to vytvoří další soubor, kde jsou popsané mé úpravy. Ono diskuse o tom, jestli já vše být v jednom souboru nebo zvlášť je stará asi jako systémy souborů. UNIX má xattr, Windows potom alternate streams. Když si vezmu mp3 soubor, tak tam jsou dva id3tagy, jeden na začátku a druhý na konci a je jen věcí náhody, jestli obsahují stejné informace a to typicky neobsahují, protože do toho na konci se toho vleze víc. Kdejaký jpeg potom obsahuje odkaz někam, kde je asi více informací nebo rovnou uuid.

Ad ty faxy a kopírky. Já se ale nebavím o HW specific formátu, tam je to důležité, ale tahle diskuse je o nějakém portable. A těch je jednak moc a žádný prohlížeč neumí všechno. Už jsem si musel napsat i konvertor do webp, protože to umí otevřít kde co, ale zapsat ne. A tohle měl být PNG, ale stačí to přejet pngcrush, což je krásně malé, ale ledacos s tím mám problém.

> Jenže tohle má každý editor RAW souborů.

Jak to má být portable, tak ten sidecar musí být standardizovaný. Takže nepotřebujete popsat ten samotný soubor s pixelama, ale ten generický a složitý sidecar file. A v té chvíli už v tom sidecaru může být i popis, jak jsou v té binárce vedle ty pixely zapakované. Uvolnit omezení z těch 16b*4 kanály už nepřinese žádné zásadní zesložitění. Jakýkoliv generický formát prostě bude složitý jak prase, protože řeší složitý problém.

> Windows potom alternate streams

Které jsou naprosto nepoužitelné. Používá je leda tak Microsoft na nekritické kešky. Formát obrázku, co se nedá nakopírovat na flešku, fakt nechcu.

21. 10. 2025, 12:09 editováno autorem komentáře

Víš jak je to se standardy. Vždy jich je N+1. LightRoom to má ve své databázi (což je sqlite včetně náhledů), potom to umí exportovat do svého sidecarfile, RapidRAW má něco svého, jestli se dá něco ukládat do DNG vlastně nevím (tak má: DNG is based on the TIFF/EP standard format, and mandates significant use of metadata.).

No a já mám třeba zařízení, které chce 5.5/2.5, protože potřebuje menší přechodový odpor pro větší proudy. A ideálně potřebuje 20 V. S 12 V fungovat umí, ale není to optimální.

Fakt je měřitelný rozdíl v odporu mezi 2.1 a 2.5mm? Mě spíš děsí konstrukce některých těch konektorů - kde to možná někde trochu kontaktuje.

Některé ty 5.5/2.1 mm konektory umí jen 30W, jiné až 100W.

Vyjednávání (nebo alespoň přenos informace jedním směrem) potřebuješ, aby zařízení vědělo, kolik proudu si může vzít (když si může např. regulovat rychlost nabíjení).

A váš nápad má ten problém, že není kompatibilní "jedním směrem" - představte si, že vyrobím zařízení, které umí 12 i 24V (není problém, dneska jsou běžné spínané zdroje, které mají velký rozsah vstupního napětí - viz třeba některé Mikrotiky, není výjimkou 9-36V). Jaký konektor bych na něj měl dát, aby ho zákazník mohl používat s takovým zdrojem, jako má zrovna po ruce?

Ne, opravdu nepotřebuje. Možná tak chcete. Ale nepotřebujete. To je rozdíl.

Jako že po každém připojení nabíječky budu zadávat, kolik smí zařízení odebírat?