Vlákno názorů k článku
Google řekl, co je potřeba pro navrácení podpory JPEG XL do Chrome
od PEAK - Milé děti,
https://www.fractionalxperience.com/ux-ui-graphic-design-blog/why-jpeg-xl-ignoring-bit-depth-is-genius
-
Teoreticky by to bolo fajn.
Prakticky si ukusuju z dalsej vrstvy abstrakcie (ako ked filesystem zacne riesit volume management) a nie som si isty, ci su ten problem pripraveni riesit (pretoze globalne je to este nedoriesene).
Totiz tak ako v SDR (referencny jas 100 nit) tie iste pixely mozu vyzerat inac v zavislosti od gamma krivky, v HDR mozu tie iste pixely vyzerat inac v zavislosti od transferovej krivky. Hodnota jasu bieleho bodu je len jeden z parametrov; percepciu riesi transferova krivka. Enkoder teda musi poznat vsetky zname a vediet, ktoru pouziva zdroj a tomu prisposobit postup kodovania.
Druhy problem je, ze uz dnes existuju farebne priestory, kde hodnota pixelu moze byt > 1.0, takze potom nastupuje bud tone mapping alebo na hulvata to orezat, v oboch pripadoch to znamena stratu dat.
Takze enkodery, ktore toto neriesia a nechaju na dalsiu vrstvu aktualne robia spravnu vec, aj ked mozu stratit nejaku efektivitu.
-
Gamma křivku a přenosové funkce potřebujete znát, když to reprezentujete v generické RGB formě. RGB bez barevného profilu barvu opravdu nedefinuje.
Ale JPEG-XL podle popisu reprezentuje barvu jako hodnoty v konkrétním barevném prostoru XYB, takže víte s absolutní jistotou, co je to za přesnou barvu.
https://facelessuser.github.io/coloraide/colors/xyb/
Znamená to ovšem, že převod do JXL musí vědět jaký je barevný prostor zdrojových dat, aby to spočítal správně.
-
Byva zazitym zvykem, ze neoznaceny RGB prostor je sRGB - jak primaries, tak transfer curve.
Az v pripade ze se jedna o cokoliv jineho (typicky z obdobi rustu digitalni fotografie), se musi prostor identifikovat.
A pak jeste tady mame RAW RGB z kamer a snimacu, ale to se vi ze to ma sve specifika per model a nejedna se o standardni prostor.
-
Neni to prvni ani posledni kodek, ktery pouziva "skrytou" krivku pro translaci mezi I/O rozhranim a internim kompresorem. Ostatne krivka je nekdy lossy komprese, jindy zase nutna kompenzace protoze sumovy profil jadra kodeku je jiny na malych a velkych cislech.
Samozrejme je vhodne, pokud kodek umi akceptovat override teto interni servisni krivky (zatim znam jen jeden takovej), a je mozne proces komprese/dekomprese trocha optimalizovat pro dany use case ci zarizeni/snimac/format.
