Photoshop - nelze uložit do JPG

Jak jednoduché milý Watsone, formát jpg umí jen 8 bitů na kanál. S 32 bity si stoprocentně neporadí.

Děkuji, bylo to ono.

Jo, muselo to být. Jen tu je teď jeden drobný problém, obrázek už není HDR. Aby byl na současných zobrazovačích (monitorech) zobrazitelný, je třeba provést tonemapping, který nezobrazitelné barvy namapuje do zobrazitelného prostoru. Pokud jsi pouze převedl z 32bit/kanál na 8bit/kanál tak jsi to nezobrazitelné pouze odřízl.

Tedy abych byl přesnější, on obrázek nebude ani potom HDR, jen bude koukatelnější a taky se trochu víc bude blížit skutečnosti. Tedy pokud z něj nastavením při tonemappingu neuděláš nekoukatelnou omalovánku.

Můžeš uložit TIFF ZIP (solidně komprimuje, 32-bit, plouvoucí) a zobrazí to např. ACDSee s přehledem.

Tady bych si dovolil upozornit, že algoritmus ZIP (stejně jako LZW) použitý u formátu TIFF není určen pro komprimaci v pohyblivé řádové čárce a tak výsledný soubor může vyjít i o něco větší než nezkomprimovaný.

To si nemyslím:http://abload.de/img/snap6707nluvz.pngTest, 36 MPix, rámec 5100x7016:PSD 409 MBTIFF ZIP 208 MB 50% stlačení.

No jo, to ale setsakramentsky záleží na obsahu. Bílý obrázek 5 184 x 3456px stlačím na nějakých 670kB (nekomprimovaná velikost 215 MB). Průměrnou fotografii stlačím tak o 10, nejvýš 20%. Nehledě na to, že prediktivní kompresi zvládá daleko méně prohlížečů než tiff komprimovaný zipem (neberu v úvahu externí pakovač). Mám obavy, že pro tazatele bude i těch 50% nepřijatelných - tiff bude přibližně stejně velký jako psd a tak se dostane na dejme tomu 80MB.A celá diskuze je stejně akademická, pokud chce obrázek někomu poslat, tak předpokládám, že dotyčný stejně nebude mít možnost si HDR prohlédnout a tudíž poslat obrázek bez tonemappingu postrádá smysl a v tom případě i posílání v bitové hloubce 32 bit/kanál. A pokud chce skutečně poslat HDR, pak je tu vhodnější formát OpenEXR.

Neukládal jsem bílý obrázek, to bych si nedovolil. Vyzkoušej si to nakonec sám.

Bez prediktivní komprese byl stejný výsledek.

A taky může slevit před uložením na 16 bitů, a uložit do JP2 ten to podporuje a zde se již může pohybovat v lossless (lepší než ZIP) nebo lossy (1:5, 1:10, 1:15 ještě jde) nebo dokonce kódovat na velikost souboru.

Jenže v tom okamžiku už HDR nebude HDR. I když si myslím, že v tomto případě nejde o HDR, ale o to co se dnes za HDR vydává. A u toho stačí těch 8bit/kanál.

Tady opět záleží na obsahu snímku. Ve většině případů je prediktivní komprese účinnější, ovšem podpora v prohlížečích je malá. Tvrdit, že komprese je taková nebo maková je velice zavádějící, pokud není zárověň uvedeno, co bylo komprimováno. Jak jsem několikrát uvedl je stupeň komprese silně závislý na obsahu a tvrdit, že je standardně např. 50% je nesmysl. U některých snímků může být i 90% (mnou uvedený extrém bílé nebo obecně jednobarevné plochy), u jiných nebude dosahovat ani zdaleka 10% a u některých bude soubor po kompresi dokonce větší.

Z toho bych Tě ani nepodezříval. Uvedl jsem to jako extrémní příklad abych ukázal jak stupeň komprese závisí na obsahu. U některých obrázků lze dosáhnout komprese vyšší, u jiných nižší. A abychom si rozuměli - já jsem netvrdil, že tiff se zip kompresí nutně bude větší než bez ní, ale že může nastat případ, kdy tomu tak bude.

Asi by bylo nejlepší, kdyby i ti co to budou prohlížet měli patřičné SW vybavení, on to pak jen stlačí 7z (ultra / LZMA2) a bude klid. Soubor to o dost stlačí a poslat dnes přes net pár mega problém není. Dokonce to může uložit třeba na SkyDrive, MEGA, GoogleDrive a je to. Pochopitelně i 16 bit sundá kvalitu dolů, ale stále je to lepší hloubka pro podání (s vyladěním jistě) než 8 bit a JPEG, který mi vždy náladovostí barev vždy připomínal AMI NTSC TV normu.

Redukcí bitové hloubky z 32 na 16bit/kanál HDR přestává být HDR.

Já nic nenamítám je to tak, ale pořád je to lepší informace než 8 bit a JPEG k tomu, jinak určitě by měl publikovat originál aby se z něj nic nevytratilo.

Bohužel to tak není. Má-li HDR být HDR je minimální bitová hloubka 32bitů na kanál. Prostý převod do nižší bitové hloubky obraz degraduje. Jediná varianta je aplikace tonemappingu. To zajistí transformaci lineární převodní "křivky" tak, aby byla respektována gama křivka (a změní se bitová hloubka tak, aby ji zobrazovací zařízení dokázala zobrazit). Je to hodně zjednodušeně řečeno, ale jiná cesta, tedy prostá redukce bitové hloubky neexistuje. Buď HDR a potom 32bit na kanál nebo LDR aplikací tonemappingu a pak jiná (menší) bitová hloubka. Publikovat originál nepůjde, neexistuje zařízení, které by to dokázalo. HDR bych přirovnal k formátu RAW ve fotoaparátu, bez převodu do "srozumitelného" tvaru ho nic nezobrazí. A tím převodem prostě nemůže být pouhá změna bitové hloubky. A tím se dostáváme zase na začátek. Archivovat (a potažmo posílat) HDR (tedy s 32bitovou hloubkou) má význam jedině v případě, že bude sloužit jako zdroj dat pro další zpracování a možná na dobu až budou existovat zařízení, která jej dokáží zobrazit. Tím zpracováním je právě tonemapping jehož výsledkem je soubor respektující vlastnosti zobrazovačů (a tiskáren). A protože v současnosti je jen u lepších monitorů bitová hloubka na kanál 10bit je plně dostačující výsledek s 8bity na kanál.

Tak ty 10 bit monitory jsou už docela v přijatelné hladině, profi OK, na doma co nevidět z toho nemám strach, nemusí se hned kupovat top model. Jinak nevím, RAW používám běžně, a když ho chci někomu poslat tak, jak je není problém, dodám k tomu specifikaci / nastavení co a jak si při "vyvolání" nastavit, popřípadě nějaké poznámky či žádané změny. Zde musí proběhnout "redukce", ale na druhou stranu, to by to neměl dělat vůbec. Nejprve si pořídit patřičný monitor (kalibrovat ho), pracovat bez ztráty kvality, a ti kterým to bude ukazovat, předvádět to samé, čili žádné kompromisy. Ale je pravda, že standardní monitor stejně houby zobrazí, protože ve skutečnosti nemá požadovanou hloubku podání, a vlastně se to jen přizpůsobuje aby to vypadalo (co monitor, to jiné zobrazení). Na opravdovou práci s takovými daty, je protřeba správné vybavení.