Odpověď na názor

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.