Připojení Retina displeje k PC

Retina displej nemusí být záležitostí pouze mobilních telefonů a tabletů. Ve varšavském hackerspace se povedlo připojit Retina displej k běžnému PC. Na 9,7 palcovém displeji s rozlišením 2048x1536 lze zobrazit nejenom xeyes nebo OpenTTD :-). Displej i s konektorem vyšel na 70 USD.

22.4.2013 13:13 | Ladislav Hagara | Zajímavý článek

Komentáře

[dizz.]

<rejp>Ja natom nevidim nic svetoborneho MacBook Pro s Retinou se uz nejakou dobu prodava</rejp>

[Aleš Kapica]

Za 70$??

[dizz.]

no za 70$ nejakou tu kuklu a velky francouzsky klic nebo velke pacidlo koupis a pak je potreba si pockat na nejakeho hipstra

Kdyz se nad tim zamyslis je to take svym zpusobem kutilstvi a zpusob jak za malo penez ziskat hodne muziky

[Kaacz]

Jak souvisi cena s upozornenim, ze Retina displej neni domenou pouze mobilu a tabletu ??

[chrono]

Predpokladám, že dizz vôbec netuší, o čom sa v tom článku píše (a áno viem, že Apple dáva Retina(tm) displej okrem mobilov a tabletov aj do notebookov).

[Kaacz]

No proste veta: Retina displej nemusí být záležitostí pouze mobilních telefonů a tabletů. je nesmysl. Protoze to tak vubec neni ..

[potato]

Takže podle tebe Retina display musí být záležitostí pouze mobilních telefonů a tabletů?

Pokud ne, tak si ujasni, s čím nesouhlasíš...

[mankind_boost]

+1.0f

[dizz.]

Ale myslim ze vim o cem se tam pise, jen mi ten nadpis prisel moc bombasticky ...

[luky]

<rejp>Ja natom nevidim nic svetoborneho MacBook Pro s Retinou se uz nejakou dobu prodava</rejp>

<rejp>Zadny prodavany macbook neni osazen dislejem, ktery splnuje definici retina displeje od Applu</rejp>

[Fluttershy, yay!]

<rejp>Retina displej je buzzword.</rejp>

[luky]

Jobs pri uvedeni rekl, ze retina displej je takovy, u ktereho jeden pixel zaujima pri bezne pozorovaci vzdalenosti mene nez 2.38e-8 srad. Z toho se da vypocist pozorovaci vzdalenost a rozhodnout, zda se da pozadovat za beznou u daneho zarizeni.

[Fluttershy, yay!]

...taky je to obchodní známka.

[dizz.]

Příloha:

• Apple - MacBook Pro - Mozilla Firefox_2013-04-23_10-05-36.png (542994 bytů)

http://www.apple.com/macbook-pro/

[luky]

Tento notebook tu definici taky nesplnuje, muzete si vygooglit rozmery jednoho pixelu a spocitat prostorovy uhel, ktery ten pixel zaujima z bezne pozorovaci vzdalenosti. Pripadne rovnou stranky, kde je to spocitane.

[dizz.]

Retina je obchodni nazev pouzivany Apple Inc. Macbook Pro je PC takze me rypnuti bylo vporadku.

[luky]

Obchodni nazev pouzivany Applem je "Retina", v clanku se pise o retina displejich, ktere sam Jobs definoval tak, jak jsem jiz uvedl. Zadny nyni prodavany MacBook neni osazeny retina displejem. Proc je ve zpravice retina s velkym R nevim.

[Fluttershy, yay!]

To je velmi kreativní způsob zacházení s přirozeným jazykem...

[motyq]

wow, že bych oprášil dlouho odkládanou stavbu fullHD projektoru a rovnou ho postavil na více-než-fullHD? To vypadá velice zajimavě a ještě jsou kabely vyvedeny bokem. Takže oholit displej o ochrané a polarizační vrstvy by nemusel být takový problém... Nice!

[dustin]

To vypadá opravdu pěkně.

[Limoto]

Chtělo by to spíš nějakej 15" a nabastlit si ho do notebooku Akorát eDP tam asi nemám

[Aleš Kapica]

Čteš mi myšlenky

[Limoto]

Na ebayi vyjde kolem $300, to už bych za to asi nedal

[Patrik Uhrak]

Veru by som bral aj ja, na mojej T410 je displej zalostny. So zvyskom som maximalne spokojny (az na zvuk).

[Fluttershy, yay!]

Tak se podívej po T60p s 2048×1536, IIRC existovala i verze s vyšší rozlišením.

[j]

Musite si uvedomit, ze na "velka PC" se to nasadit neda ... neb widle (ani OS ani apps) nejsou schopny neco takovyho pobrat, a cist na tom pismenka 8x8px ... asi nebude moc posusnani ;D.

Mozna za 20let prijde M$ s tim, ze konecne umi pocitat z vyrazne vyssim DPI.

[Fluttershy, yay!]

IBM T221 bohužel zmizelo právě z tohoto důvodu, ale MS Windows se prý od XP docela posunula.

[Ovocníček]

Oni ti to neposerou ani tak Windows, jako ostatní programy. Což je na jednu stranu omluva, na druhou stranu je to ještě horší :/

[j]

Pry nebo si to zkousel? Ja to zkousel, nezmenilo se vubec nic. Polovina GUI se pekne rozpadne, druhou dorazi aplikace, ktery maj vsechno fixne "na pixel" ...

Je to uplne stejny jako weby, kde se to snazej vyresit prohlizece porusovanim normy (viz i tady zpravicky ohledne podpory retina ve FF a spol) misto toho, aby s web nekdo spravne napsal (tzn pouzil jakekoli rozumne jednotky krom px).

[Fluttershy, yay!]

To mám od člověka, který T221 používá. Já na MS Windows skoro nesahám a už vůbec ne s něčím s vysokým dpi.

[Marv-CZ]

Proč by se nemohly používat jednotky px? Podle W3C standardů se totiž 1 px NEROVNÁ 1 fyzický bod displeje. Pokud to způsobem 1:1 prohlížeč na na retina displejích zobrazuje, je to chyba prohlížeče, ne stránky.

[Josef Kufner]

Přesně tak. Viz specifikace CSS:

‘px’ = pixels; 1px is equal to 1/96th of 1in

For a CSS device, these dimensions are either anchored (i) by relating the physical units to their physical measurements, or (ii) by relating the pixel unit to the reference pixel. For print media and similar high-resolution devices, the anchor unit should be one of the standard physical units (inches, centimeters, etc). For lower-resolution devices, and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.

The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch).

[j]

Vazne ... tak to by me zajimalo, jak ze udela 1/3 px ...

[Jiří J.]

Jednobarevně 

[Heron]

[the.max]

+1

[David Jaša]

takhle (odtud)

[little.owl]

Tak jiste, tohle jde, i kdyz je to takove vizualni saleni lidskeho zraku, kde se snadno narazi na limity a side-effecty.

Dobry link.

[little.owl]

Pokud je referencni pixel 0.0213 stupne, tak na referencnim monitoru o sirce 1280 pixelu tomu odpovida 27.264 stupne, coz by davalo celkem smysl, nebot clovek je schopen pohodlne sledovat informaci v tomto uhlu aniz by diky podvedome koordinaci oci a hlavy prilis natacel hlavu (velky vliv na unavu). U monitoru se sirkou 1920 pixelu to jiz je to 40.896 stupnu, coz uz je vyrazne horsi.Ten jejich reasoning zatim by me zajimal.

[Libor Klepac]

no ja nevim, ve windows8 je neco jako soupatko "velikost", ktere je spolecne pro vsechny displaye. Takze sef, ktery ma 12'' xps s fullhd rozlisenim a 24'' LCD display take s fullhd rozlisenim ma docela problem.

Kdyz si nastavi 150%, tak ma tak akorat velikost pisma na ntb, kdyz si nastavi 100% tak na LCD.

Akorat ze mezi zmenou je treba se minimalne odhlasit ... no a pak si ze me dela srandu, ze pouzivam studenstky software ;)

[David Jaša]

Tenhle argument slýchám už asi tak 7 let. Kdyby místo výmluv nezprasili několik dalších verzí jejich GUI frameworků a doporučili výrobcům monitorů (notebooků) DPI zvedat, mohlo dnes už být 200+ DPI samozřejmost.

[petr_p]

Bohužel idiocie vládne světu. I Xorg chce být „kompatibilní“ za každou cenu.

[j]

Jop, bohuzel se tenhle trotloidni pristup presunuje i do tucnaka ... i kdyz na druhou stranu, jeste vic miluju likvidaci funkcnich veci ve jmenu ideologie ... viz fake raid (od 2.6.18+ nefunkcni R5) ... viz udev ... a vyhozeni moznosti dat sitovce mnou zvolene ethX jmeno ...

[little.owl]

... a vyhozeni moznosti dat sitovce mnou zvolene ethX jmeno ...

A to mate odkud?

[j]

Vlastni zkusenost ...

jinak trebas:

2013-01-23-udev-upgrade Title Upgrading udev from 171 (or older) to 197 (or newer) Author Samuli Suominen Posted 2013-01-23 Revision 1

Upgrading udev from 171 (or older) to 197 (or newer) will require special attention:

- Remove udev-postmount from runlevels.

- The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the fstype for possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs)

- The case of predictable network interface names; if the file /etc/udev/rules.d/70-persistent-net.rules is being used for renaming network interface names to already existing names, then you need to read following bug[1] because it's no longer possible. This won't be a problem with the new predictable network interface name scheme[2].

[1] http://bugs.gentoo.org/453494 [2] http://www.freedesktop.org/wiki/Software/systemd/ PredictableNetworkInterfaceNames

- The case of separate /usr; if it worked for you with 171 it will continue to work for you with 197 (or newer). We still recommend initramfs with separate /usr mounting capabilities because you might need packages like sys-apps/kbd (keymaps in /usr) or net-wireless/bluez (possible keyboard) in early boot.

And read every message printed by the emerge of udev and udev-init-scripts to ensure the system is in order before booting as this news item might not be complete.

[little.owl]

I v te diskusi u bugu na ktery odkazujete mate reseni. Je takovy problem si precist dokumentaci primo uz zdroje zde? Stale mi chcete tvrdit

... a vyhozeni moznosti dat sitovce mnou zvolene ethX jmeno ...

je platne tvrzeni?

[j]

Je to 100% PLATNE tvrzeni. Ano, muzu si sitovku pojmenovat jinak ... a prepsat vsechny konfiguraky co kde v systemu jsou. Staci se naucit cist, ze ... eth0 z eth1 proste jiz udelat nelze a to nijak (bez hackovani kodu samo).

Jen pro ty mene gramotne:

You basically have three options:

=> mam 3 moznosti reseni

1) ponechat na kernelu jak sitovky pojmenuje (=> jinak nez chci, pojmenovani se muze menit v zavislosti "na pocasi")

2) pojmenovat si sitovky jinak (trebas net0, net1 ... nebo internet, lan, wan ...) a prepsat vsechny konfiguraky v systemu - za pouziti vlastnich pravidel

3) muzu prepsat defaultni pravidla (a pojmenovat si trebas sitovky podle mac adresy + opet prepsat vse ostatni) ...

V ZADNEM pripade ale NEMUZU prejmenovat eth0 na eth1 a naopak (s pomoci MAC adresy jako identifikatoru)! Eth je prave od teto zmeny vyhradnim jmenym prostorem kernelu do kteryho nemuzu zasahnout. Ve starsi verzi udevu byl kod, ktery to umoznoval.

Toto neni jiz dale funkcni:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0e:0b:56:7c:d3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

[Luboš Doležel (Doli)]

Ježiši... Kdyby to hackovali v prohlížečích, tak nic neřeknu, ale v X11?!

[Ondrej 'SanTiago' Zajicek]

No, nema smysl to hazet na Windows, vetsina Linuxovych GUI a aplikaci s tim bude mit obdobne problemy. Asi jedine reseni, ktere by zajistilo jak kompatibilitu, tak vyuziti moznosti displeju s vysokym DPI. je reseni a la HTML 4 CSS, kde fonty se budou renderovat ve vyssim rozliseni, ale pixmapy dodavane aplikacema bude toolkit upscalovat (predpokladat, ze jsou v nominalnim 96 DPI) a obdobne se bude toolkit chovat k 'pixelovym' jednotkam, pokud aplikace nepouzije nove API, ktere umozni specifikovat i DPI pixmapy.

Jinak DPI neni zas tak dulezite, podstatnejsi je pocet pixelu na uhel, takze z normalniho monitoru clovek muze udelat 'retina' displej (o polovicni uhlopricce) proste tak, ze si sedne od nej dvakrat tak daleko (coz porad bude jeste v mezich optimalni vzdalenosti co se tyce moznosti oka).

[j]

To neni reseni, to je primo megapruser.

Co myslis, budou kazdy 2-3 mesice pridavat prepocet pro jiny konkretni zobrazovadlo, ktery ma jiny konkretni DPI? A co kdyz jako vyvojar budou pouzivat mozek a zeptam se prohlizece a predlozim mu web presne tak, jak bych ho chtel na takovym zobrazovadle ... tak ho prohlizec naprosto zmrvi ... Nehlede vubec na to, ze kdyz chci neco presne 1px, tak to chci 1px naprosto bez ohledu na to, jaky je cilovy zobrazovadlo (a beru samo v potaz, ze user si muze zmenit uplne vse, ale v defaultu by to melo byt 1px).

Pak to bude za par mesicu vypadat jako "drivery" pro graficky karty - 5MB ovladacu a 250MB vyjimek pro konkretni binarky ...

[Ondrej 'SanTiago' Zajicek]

Co myslis, budou kazdy 2-3 mesice pridavat prepocet pro jiny konkretni zobrazovadlo, ktery ma jiny konkretni DPI?

Zadne prepocty pro konkretni zobrazovadla nejsou treba.

A co kdyz jako vyvojar budou pouzivat mozek a zeptam se prohlizece a predlozim mu web presne tak, jak bych ho chtel na takovym zobrazovadle ... tak ho prohlizec naprosto zmrvi

Prohlizec to zobrazi v souladu se standardem, to jen ten vyvojar ocekava neco jineho, nez co je mu nabizeno.

[biolog]

Automatické přeškálování bitmap z aplikací systémem je právě kvůli takovýmhle programátorům, co to chtějí 1px naprosto bez ohledu na to, jaký je cílové zobrazovadlo. Programátor si buď zjistí DPI a vypočte bitmapu podle toho (a řekne řekne systému, že lepší hodnotu DPI už zohlednil) a nebo se nebo se na to vykašle a přeškáluje to až OS. Většině aplikací stačí škálování OSem/toolkitem.

A přidávání přepočtu každých pár měsíců? Ten přepočet vyplývá z vlastností displeje, fyzické rozměry i rozlišení jsou uložené v něm.

[Franta]

je reseni a la HTML 4 CSS, kde fonty se budou renderovat ve vyssim rozliseni, ale pixmapy dodavane aplikacema bude toolkit upscalovat

Nebo se na bitmapy vykašlat a pro GUI používat vektory (když už tam musí být obrázky – např. ikony).

[Ondrej 'SanTiago' Zajicek]

U mlaych objektu malokdy budes schopen udelat vektorove ikony takove, aby byly pekne pri libovolnem rozliseni (protoze nejde jen o scaling, ale i napr. o eliminaci detailu). To uz je jednodussi si pripravit pixmapy pro ruzna rozliseni s krokem treba sqrt(2). A treba udelat hru s isometrickou grafikou, ktera by byla plne vektorove skalovatelna, je naprosto nerealisticke.

[Marv-CZ]

Ikony se správně chystají optimalizované bitmapové pro malé velikosti (16px, 32px, ...) a zároveň i vektorové, ze kterých si systém dopočítá kteroukoliv potřebnou větší velikosti.

Když je potřeba bitmapa, třeba fotka, tak se připraví v hodně velkém rozlišení a systém si ji podle potřeby downscaluje.

[xkucf03]

jj, s tím souhlasím, je potřeba různá úroveň detailu, ne jen zmenšování/zvětšování, ale i tak mi přijdou ty vektory lepší, protože stačí třeba 2-3 úrovně detailu (varianty) a zbytek lze plynule škálovat.

[Josef Kufner]

Na Linuxu není problém používat "obří" fonty i vektorové ikonky. KDE i GNOME tohle zvládají pěkně. Otázkou je, co na to trh s PC. Na druhou stranu by to mohla být velká konkurenční výhoda pro Ubuntu.

[Marv-CZ]

Jenže Ubuntu nepoužívá Gnome Shell, ale bastlí si vlastní Unity. A třeba u jejich Software centra používají bitmapové ikony, i když je s aplikací dodávaná i vektorová, takže výsledek je kvality alá Windows.

[Josef Kufner]

Tak to je otázkou jen nějakého toho bugreportu.

[jehovista]

A bugreport to vyresi?

[little.owl]

Takze list neresenych bugu opet naroste. A co dal?

[Jirka]

Jé, to chci!
Objednám, vezmu trafopájku a za chvíli hotovo!

[Grunt]

To OTTD vypadá zatraceně dobře. Ten těch retin jen pár spárovat aspoň tak do formátu A0.

[mikirc]

Ja se spise zeptam: Na co? Na co tak male rozliseni na tak male obrazovce, stejne to oko neni schopne rozlisit. A nikdo nehledi na displej z 20-30cm

[David Jaša]

Na co tak male rozliseni na tak male obrazovce, stejne to oko neni schopne rozlisit

To je právě cílem. Při dostatečně malém bodu se konečně může zahodit hinting, antialiasing a podobné lahůdky.

[Grunt]

A můžeme zapnout dithering nebo noise-shaping, že? Díky moc.

[Grunt]

A na zahození barev jsem zapomenul.

[little.owl]

Efektivni zvyseni rozliseni znamena zvyseni sirky prenosoveho pasma a ted mi vysvetlete jak to vadi.

[Grunt]

zvyseni sirky prenosoveho pasma

Že to nikdo dělat nebude (kdo by to taky platil?) a bitová hloubka bude padat na úkor rozlišení až na 1-bit.

[little.owl]

zvyseni sirky prenosoveho pasma

Že to nikdo dělat nebude (kdo by to taky platil?) a bitová hloubka bude padat na úkor rozlišení až na 1-bit.

Chcete mi tvrdit, ze soucasny bottleneck u graficka karta->screen je sirka pasma na strane zdoje ci kabelu/media? Videl jste soucasne hodnoty u HDMI?

[Grunt]

Czech please. Ví dů not andrsténd…

[little.owl]

bottleneck == uzke hrdlo, limitujici prvek/faktor

screen == obrazovka

[Grunt]

S tím problém nemám. Tomu rozumím, ale nevím co se tím snaží básník říct.

[little.owl]

Vy me zkuste vysvetlit vase tvrzeni nahore. Jako:

Že to nikdo dělat nebude (kdo by to taky platil?) a bitová hloubka bude padat na úkor rozlišení až na 1-bit.

ci

A můžeme zapnout dithering nebo noise-shaping, že?

Mluvime stale o PC nebo TV?

[Grunt]

Přílohy:

• Lenna_original_gray.png (223593 bytů)
• Lenna_monochrome.png (31010 bytů)
• Lenna_1024_mono.png (120579 bytů)
• Lenna_1024_smooth.png (243922 bytů)
• Lenna_1500_smooth.png (244386 bytů)
• Lenna_2048_mono.png (474234 bytů)
• Lenna_2048_mono.png (474234 bytů)

Spíš ho budu demonstrovat. Na Leně (Lenna_original_gray.png). Pokud ho zkvantuju do hloubky 1-bit:

$convert Lenna_original_gray.png -remap pattern:gray50 Lenna_monochrome.png

prostě není co řešit. Šírka pásma je naprosto nedostatečná (v tomhle případě způsobené nedostatečnou bitovou hloubkou) a je to na první pohled viditelné. Pokud zvětším rozlišení třeba na jednou tak veliké ale zachovám bitovou hloubku, zvednu také potřebnou šířku pásma (kalkulace nechť si laskavý čtenář udělá sám):

convert Lenna_original_gray.png -resize 1024x1024 -remap pattern:gray50 Lenna_1024_mono.png

teď už jen zbývá emulovat vzdálenost hlavy od monitoru. To je v podstatě low-pass filtering, a to můžu naemulovat zmenším zpět do původního rozlišení:

$ convert Lenna_original_gray.png -resize 1024x1024 -remap pattern:gray50 -resize 512x512 Lenna_1024_smooth.png

Už jen zbývá otázka jaké rozlišení je dostatečně vysoké na to aby lidské oko nepostřehlo že jde o kvantovací hloubku 1-bit na kanál:

$ convert Lenna_original_gray.png -resize 1500x1500 -remap pattern:gray50 -resize 512x512 Lenna_1500_smooth.png

1500x1500, tedy třikrát větší? No začne to miznout tak u 2048x2048 (tedy čtyřnásobného rozlišení):

$ convert Lenna_original_gray.png -resize 2048x2048 -remap pattern:gray50 Lenna_2048_mono.png
$ convert.exe Lenna_2048_mono.png -resize 512x512 Lenna_2048_smooth.png

Jenže za jakou cenu? Odborně se tomu říká oversampling a vítám tě ve světě ΔΣ. U zvukovek už se to nějaké to desetiletí běžně používá (jsou to všelijaké ty High-definition audia), u tiskáren taky (barvy jsou jen tři) a logicky je tak na řadě obraz. Už se nemůžu dočkat závratných rozlišení jako 16000x9000, akorát že jde tak o 4,3,2 nebo dokonce 1 bit na pixel se už se jaksi zapomene v propagačním listu zmínit.

[Grunt]

Příloha:

• Lenna_2048_smooth.png (238373 bytů)

Sakra, mam tam dvakrát Lenna_2048_mono.png.

[dustin]

Delta sigma modulace u zvukovek je jedna z technologií DA převodu, interní věc převodníku (čipu). S high definition (tedy větší rozlišení než 48/16) to nemá absolutně nic společného. Oversampling neznamená automaticky snížení bitového rozlišení, ne-delta-sigma DA převodníky jej používají také. Důvodem je zjednodušení (zreálnění) konstrukce analogového filtru za převodníkem, který nemusí být tak ostrý.

Ten displej použitý v původní konstrukci má rozlišení 24bitů na pixel.

[little.owl]

Důvodem je zjednodušení (zreálnění) konstrukce analogového filtru za převodníkem, který nemusí být tak ostrý.

Presne tak. Usetri se na low pass cut-off filtrech, ktere nemusi byt tak strme. Jednoduchy filtr, low-res oversampling, digitalni decimacni filtr a je to.

[little.owl]

Vim co to je oversampling ci dithering, digital signal processingem se zabyvam a dokonce jsem za to dostal i nejaky titul. Ten obrazek je tak notoricky znamy, az je mi z nej uz k zbliti, poprve jsem s nim delal v Matlabu v roce 1998. Pointa je v tom, ze je tohle vase cviceni je zcela irelevantni.

S vyjimkou bitmap s nizkym rozlisenim, neni u hires displayu co resit a v takovem pripade mluvime o upsampling-u a vzdy je tam zahrnuta nejaka forma interpolace.

K kontextu s vasi patickou to vypada, ze se nekdo nevyspal z nadseni ze sigma-delta modulace.

logicky je tak na řadě obraz.

Zatim neni. V tom je jadro nesmyslnosti vasi argumentace. Vy predpokladate jinou technologii a na zaklade toho pak predhazujete v soucasnosti irelevantni problemy spojene treba s [vizualni] decimaci.

[David Jaša]

nemyslím si, že by 1200 dpi stačilo na podobné techniky u monitorů, odhadem bych to viděl na několikanásobek.

[little.owl]

Ano, jen z pohledu ekvivalentniho prenosu jasu to vychazi na tak od 5000 dpi.

Tohle je opravdu science fiction, ja budu happy uz jen za dostupny a podporovany 4096x2304/20-24".

[David Jaša]

Jo jo, chtělo by to přelézt 200 dpi.

[Grunt]

Neřekl jsem, že když u Lenny stačí čtyřnásobné rozlišení k zamaskování kvantizace, bude to stačit i u obrazu. Lenna je Lenna, obrazovka je obrazovka. Vycházel bych třeba z tiskáren. Černobílý tisk jsou v podstatě též dvě kvantizační hodnoty (bílý papír, černý inkoust, u barev se do toho ještě míchají tři další barevné pigmenty) a jaké jsou hodnoty? 300x300dpi, 600x600dpi (pokud odhlédnehe od faktu že si výrobci stříkají na papír co chtějí nezávisle na hodnotě dpi), atd. Z toho bych vycházel já.

[Grunt]

Neřekl jsem, že když u Lenny stačí čtyřnásobné rozlišení k zamaskování kvantizace, bude to stačit i u obrazu.

Mimochodem, nestačí. Doporučuju srovnat originál a 2048_smooth. Vysokofrekvenční kvantizační šum je patrný furt. Ale to je taky to o čem mluvím. Pustí se do boje noise-shaping a už stačit dle výrobců bude.

[little.owl]

a už stačit dle výrobců bude.

Jakych? Nejaky odkaz?

Zatim jsem krome eink/epaper panelu nevidel nikoho, kdo by se timto prilis zabyval.

Tech cest, jak to resit je plno, kombinace vhodneho dithering algoritmu, pouziti optickeho low pass filteru jako u CMOS sensoru ci uziti stavajici FLC modulace pro kontrolu jasu a nizsiho rozliseni.

[Grunt]

BTW, „==“ je operátor porovnání a ne přiřazení.