Autor | Zpráva | ||
---|---|---|---|
pavuk Profil |
#1 · Zasláno: 20. 3. 2010, 19:39:03
Zdravím vás při večeru
Nikdy jsem následující problém neměl, až od včerejší reinstalace Gimpu (ovšem jestli to má souvislost netuším). Zkoušel jsem uložit postupně ve formátu .png, .gif i .jpg, měnit parametry při ukládání, použít vyhlazování, ale nemůžu docílit plynulýho barevnýho přechodu. Při práci v Gimpu plynulý přechody jsou. Můžete mě nakopnout směrem k řešení? Díky odkaz |
||
DoubleThink Profil * |
#2 · Zasláno: 20. 3. 2010, 20:01:39
GIF a 8-bitový PNG může obsahovat jen 256 barev. To je na hladký gradient většinou málo.
|
||
Nox Profil |
#3 · Zasláno: 20. 3. 2010, 20:03:58
DoubleThink:
Stejný problém jsem měl ve Photoshopu v *.psd při 32 bitech, tam fakt nehrozí nízký počet barev....bohužel jsem to nevyřešil |
||
pavuk Profil |
#4 · Zasláno: 20. 3. 2010, 20:08:39
Skoro dobrýho výsledku jsem dosáhl jenom v .jpg s vyhlazením na plno a kvalitou 100%, přesto to není pořád ono. Nevědomky jsem musel někde něco zašantročit, protože předtím jsem s tím žádný problémy neměl... Nevím co s tím.
Mám dojem že na ten jev existuje nějakej výraz, ale nedokážu si vzpomenout a proto je hledání naprosto ztracený, na "barevný přechody" to vyhazuje tisíce výsledků, ale nejsem z nich moudrej, navíc většina se týká tisku přechodů... |
||
pavuk Profil |
#5 · Zasláno: 20. 3. 2010, 20:28:04
Podařilo se mi dopátrat že to řeší tzv. "dithering", ale mám dojem že v Gimpu nic takovýho bohužel neznám
|
||
Petr ZZZ Profil |
#6 · Zasláno: 20. 3. 2010, 23:30:24 · Upravil/a: Petr ZZZ
pavuk:
Plynulost barevných přechodů mě taky občas dokáže potrápit; většinou se mi to podaří vyřešit ve fotošopu, někdy lépe, někdy hůře. Zkus se podívat na přehled efektů filtrů, zvláště na rozostřovací filtr (Gaussovské rozostření) a šumový filtr (přidat šum). Je to potřeba vyzkoušet a mám podezření, že výsledky se mohou lišit taky podle rozlišení původního obrázku (což bych po pravdě nečekal, vždyť jde o rozostření). Gimp by snad měl podobné funkce taky nabízet. Alternativně by se možná dal vyfotit problematický přechod z obrazovky rozostřeným digitálním foťákem (asi lépe ze stativu). |
||
pavuk Profil |
#7 · Zasláno: 21. 3. 2010, 07:52:28
Petr ZZZ:
Gimp tyhle filtry taky nabízí a přechod není problém (viz.[#1]), problém vznikne až při uložení obrázku s přechodem. Při práci samotný je přechod v pohodě. Až na ten uloženej výsledek... |
||
Petr ZZZ Profil |
#8 · Zasláno: 21. 3. 2010, 09:53:10
pavuk:
A zkoušel jsi uložit obrázek jako JPEG v původní velikosti a až potom ho zmenšit na velikost, jakou potřebuješ pro web? Například obrázek s Capnodisem na mém webu vznikal zhruba takto: 1. Diapozitiv s nevhodným pozadím. 2. Naskenován ve formátu TIFF. 3. Kopie převedena do formátu JPEG. 4. Původní obrázek mírně ořezán na velikost 4689 x 3126 px. 5. Vytvořen výběr hlavního motivu, pozadí odstraněno a nahrazeno jiným, které jsem vyrobil ze snímku krajiny extrémním rozostřením (Gaussovské rozostření, šumový filtr, viz [#6]). 6. Doplněn text s copyrightem. 7. Obrázek zmenšen na 800 x 533 px. |
||
pavuk Profil |
#9 · Zasláno: 21. 3. 2010, 10:09:41
nezkoušel, protože ty obrázky od počátku vytvářím... V uvedeným odkazu je sice použitej obrázek staženej z netu, ale ten problém je i u nově vzniklejch obrázků s přechodama, který dělám v Gimpu
|
||
Petr ZZZ Profil |
#10 · Zasláno: 21. 3. 2010, 10:31:43 · Upravil/a: Petr ZZZ
Tak jestli to jinak nepůjde řešit, tak asi postavit foťák na stativ a vyfotit část obrazovky s požadovaným motivem. Předtím foťák mírně rozostřit, aby to nebralo mřížku obrazovky (možná i rozostřit víc a zato trochu zaclonit, aby ses vyhnul vinětování). Až potom snímek digitálně upravovat (výřez, velikost...).
Dodatek: Ještě mě napadl takový pokus: Dokud jsou přechody v Gimpu v pořádku, udělat screenshot, ten hodit Ctrl+V do Powerpointu, tam uložit jako JPEG a ten v Gimpu dokončit a uložit. Když tak napiš, jak to dopadlo. |
||
pavuk Profil |
#11 · Zasláno: 21. 3. 2010, 11:46:51
V .jpg to jde, ale já se mu chtěl vyhnout a udělat to v .gifu, v tom byl zakopanej pes.
Jinak je situace vyřešená: smázl jsem to všechno a vytvořil v Gimpu úplně novej obrázek, kterej se zobrazuje korektně. Zřejmě teda byl problém v tom, že jsem přetvářel původní .jpg |
||
Petr ZZZ Profil |
#12 · Zasláno: 21. 3. 2010, 12:39:02
Ke gifu mě ještě napadá upřesnění ohledně počtu barev. On gif umí zobrazit jakoukoli barvu, kterou lze zapsat šestimístným hexadecimálním číslem, čili jakoukoli z celkového počtu 16.777.216 barev, akorát jeden gif neumí víc než 256 barev současně, jak píše DoubleThink. Které barvy to ale jsou, to je fuk. Existují také postupy (asi ten dithering), které u jednoho gifu dokážou víc než 256 barev takříkajíc simulovat. Něco jsem o gifu vygůglil, zatím jsem to jen proletěl, ale na první pohled to vypadá celkem zajímavě:
Případ GIF Pravda a mýty o GIFu |
||
Časová prodleva: 2 roky
|
|||
fisheye Profil |
#13 · Zasláno: 25. 3. 2012, 03:28:12
Já bych si dovolil jednu poznámku k tématu, ačkoli je vlákno dost staré, zdá se stále horké. Přechod barev, neboli gradient, je plynulé rozvrstvení mezi dvěma barevnými hodnotami na určitém počtu pixelů. Nesouvisí to úplně s Gimpem, ale např. Photoshop dovoluje vytvořit i komplexní gradienty, tj. nikoli od barvy A do barvy B, ale od A k B a od B k C, takže vznikne něco jako gradientová zebra.
Teď k tématu. Pokud chci přechod od #000 k #fff a mám na to 100px, dostanu plynule 100 hodnot, což se zdá celkem ok a gradient působí dojmem plynulého přechodu. Pokud ovšem na rozmezí 100px vytvořím gradient od #000 do #111, dostanu pouhých 17 hodnot (17 kroků RGB). V rámci 100px je pak gradient nikoliv plynulý, ale složený z proužků o šířce asi 14px. Proto působí jako jednotlivé "zuby". Aby byl plynulý, musí obsahovat nejméně 100 hodnot, což odpovídá třeba rozdílu mezi #000 a #646464 (RGB 0-100). Řešením tedy nebude vyhlazení, ale vytvoření dostatečného počtu hodnot mezi krajními body gradientu. |
||
Bubák Profil |
#14 · Zasláno: 25. 3. 2012, 09:56:51
fisheye:
„Aby byl plynulý, musí obsahovat nejméně 100 hodnot, což odpovídá třeba rozdílu mezi #000 a #646464 (RGB 0-100).“ Nemáš pravdu. Je to tak, správná připomínka. V případě, že se takový přechod zobrazuje za zařízení, které není schopné není schopné zobrazit všech 16,7 miliónů barev, v dnešní době to jsou hlavně levné LCD zobrazovače. |
||
fisheye Profil |
#15 · Zasláno: 25. 3. 2012, 12:32:49
Bubák:
Je to tak. Ale myslel jsem, že se nebavíme o problematice "co umí display" ale o to, co skutečně v bitmapě bude. Jak se to zobrazí je zas jiná věc. Blbej gradient se zobrazí blbě vždycky. |
||
Petr ZZZ Profil |
Reaguji na fisheye:
„Pokud ovšem na rozmezí 100px vytvořím gradient od #000 do #111, dostanu pouhých 17 hodnot (17 kroků RGB). V rámci 100px je pak gradient nikoliv plynulý, ale složený z proužků o šířce asi 14px. Proto působí jako jednotlivé "zuby".“ Předpokládám, že to je jen teoretická úvaha a nemáš to vyzkoušené. #000000 #010101 #020202 #030303 #040404 #050505 #060606 #070707 #080808 #090909 #0a0a0a #0b0b0b #0c0c0c #0d0d0d #0e0e0e #0f0f0f #101010 #111111 #121212 #131313 #141414 #151515 #161616 #171717 #181818 #191919 #1a1a1a #1b1b1b #1c1c1c #1d1d1d #1e1e1e #1f1f1f #202020 #212121 #222222 #232323 #242424 #252525 #262626 #272727 #282828 #292929 #2a2a2a #2b2b2b #2c2c2c #2d2d2d #2e2e2e #2f2f2f #303030 #313131 #323232 #333333 #343434 #353535 #363636 #373737 #383838 #393939 #3a3a3a #3b3b3b #3c3c3c #3d3d3d #3e3e3e #3f3f3f #404040 #414141 #424242 #434343 #444444 #454545 #464646 #474747 #484848 #494949 #4a4a4a #4b4b4b #4c4c4c #4d4d4d #4e4e4e #4f4f4f #505050 #515151 #525252 #535353 #545454 #555555 #565656 #575757 #585858 #595959 #5a5a5a #5b5b5b #5c5c5c #5d5d5d #5e5e5e #5f5f5f #606060 #616161 #626262 #636363 #646464 #656565 #666666 #676767 #686868 #696969 #6a6a6a #6b6b6b #6c6c6c #6d6d6d #6e6e6e #6f6f6f #707070 #717171 #727272 #737373 #747474 #757575 #767676 #777777 #787878 #797979 #7a7a7a #7b7b7b #7c7c7c #7d7d7d #7e7e7e #7f7f7f #808080 #818181 #828282 #838383 #848484 #858585 #868686 #878787 #888888 #898989 #8a8a8a #8b8b8b #8c8c8c #8d8d8d #8e8e8e #8f8f8f #909090 #919191 #929292 #939393 #949494 #959595 #969696 #979797 #989898 #999999 #9a9a9a #9b9b9b #9c9c9c #9d9d9d #9e9e9e #9f9f9f #a0a0a0 #a1a1a1 #a2a2a2 #a3a3a3 #a4a4a4 #a5a5a5 #a6a6a6 #a7a7a7 #a8a8a8 #a9a9a9 #aaaaaa #ababab #acacac #adadad #aeaeae #afafaf #b0b0b0 #b1b1b1 #b2b2b2 #b3b3b3 #b4b4b4 #b5b5b5 #b6b6b6 #b7b7b7 #b8b8b8 #b9b9b9 #bababa #bbbbbb #bcbcbc #bdbdbd #bebebe #bfbfbf #c0c0c0 #c1c1c1 #c2c2c2 #c3c3c3 #c4c4c4 #c5c5c5 #c6c6c6 #c7c7c7 #c8c8c8 #c9c9c9 #cacaca #cbcbcb #cccccc #cdcdcd #cecece #cfcfcf #d0d0d0 #d1d1d1 #d2d2d2 #d3d3d3 #d4d4d4 #d5d5d5 #d6d6d6 #d7d7d7 #d8d8d8 #d9d9d9 #dadada #dbdbdb #dcdcdc #dddddd #dedede #dfdfdf #e0e0e0 #e1e1e1 #e2e2e2 #e3e3e3 #e4e4e4 #e5e5e5 #e6e6e6 #e7e7e7 #e8e8e8 #e9e9e9 #eaeaea #ebebeb #ececec #ededed #eeeeee #efefef #f0f0f0 #f1f1f1 #f2f2f2 #f3f3f3 #f4f4f4 #f5f5f5 #f6f6f6 #f7f7f7 #f8f8f8 #f9f9f9 #fafafa #fbfbfb #fcfcfc #fdfdfd #fefefe #ffffff ...a to jsou jen odstíny šedé. Tvoje úvaha má totiž jeden háček: Barvy se kódují v šestimístném hexadecimálním kódování – například trojmístné #100 zde platí jen jako zkrácený zápis ve skutečnosti šestimístného čísla #110000, #cfd zastupuje číslo #ccffdd atd. Takto však lze zkrátit jen 4096 barev (nejvyšší trojmístné hexadecimální číslo, fff, odpovídá decimálnímu číslu 4095, plus nula, která kóduje černou). Většinu hexadecimálních čísel (třeba #a3f8bb) takto zkrátit nelze a mezi nulou ("šestimístným hexadecimálním 000000") a šestimístným hexadecimálním 111111 je víc než milión hodnot (přesně 1.118.481). Sousední odstíny od sebe lidské oko nerozezná (to je taky důvod, proč na barevných digitálních fotografiích nevidíme rozdíl oproti skutečnosti). Pokud se někde zobrazí zuby, nemusí tedy být na vině kódovaný rozsah barevného přechodu, ale rozlišovací schopnost výstupního zařízení. |
||
fisheye Profil |
#17 · Zasláno: 26. 3. 2012, 12:42:49
Petr ZZZ:
Ahoj, tak nevím, jestli na tom mám reagovat, ale na vektoru #000000 -> #111111 vidím pořád 17+1 hodnot, tedy pokud si rozumíme, samozřejmě, že se to dá napadnout ze všech stran, ale nemám energii popsat celý problém ze všech stran, osobně bych mohl dát dalších 5 argumentů, proč to není pravda. Ale v zásadě jsem měl na mysli to, že pokud gradient neobsahuje dost hodnot, nejde ho vyhladit. |
||
Chamurappi Profil |
#18 · Zasláno: 26. 3. 2012, 14:50:31
Reaguji na fisheye:
„pokud gradient neobsahuje dost hodnot, nejde ho vyhladit“ Viditelnou pruhatost jde ale zamaskovat již dříve zmíněným ditheringem. Promícháním pixelů se už tak dost nepatrný rozdíl ještě víc rozptýlí… |
||
_es Profil |
#19 · Zasláno: 26. 3. 2012, 15:17:16
Neviem, pre aké všetky zobrazovače to platí, no niekde môže byť rozhranie dvoch farieb umelo zvýraznené - vraj to zvyšuje ostrosť výsledného obrazu.
|
||
Časová prodleva: 2 měsíce
|
|||
Petr ZZZ Profil |
#20 · Zasláno: 23. 5. 2012, 17:46:54
Reaguji na fisheye:
„nevím, jestli na to mám reagovat...“ Nic si z toho nedělej, taky jsem právě dva měsíce přemýšlel, jestli mám reagovat. :-) „...ale na vektoru #000000 -> #111111 vidím pořád 17+1 hodnot“ Pokusil jsem se vysvětlit, že těch hodnot lze zapsat víc než milión... „nemám energii popsat celý problém ze všech stran, osobně bych mohl dát dalších 5 argumentů, proč to není pravda.“ Tak mi prosím dej aspoň jeden, rád bych věděl, v čem dělám chybu. Nakonec je-li argument správný, měl by na vyvrácení nesprávné myšlenky principiálně jeden stačit. |
||
_es Profil |
#21 · Zasláno: 23. 5. 2012, 18:02:31
Petr ZZZ:
„mezi nulou ("šestimístným hexadecimálním 000000") a šestimístným hexadecimálním 111111 je víc než milión hodnot (přesně 1.118.481).“ Ale v lineárnom prechode v 24 bitovom farebnom rozlíšení ich je len 16. Spraviť gradient prechodu čiernej na tmavosivú cez odtiene červenej či fialovej by asi veľmi dobre nevyzeralo. |
||
Petr ZZZ Profil |
Reaguji na _es:
„Ale v lineárnom prechode v 24 bitovom farebnom rozlíšení ich je len 16.“ To se už ale bavíme o nedokonalosti výstupního zařízení, ne? „Spraviť gradient prechodu čiernej na tmavosivú cez odtiene červenej či fialovej by asi veľmi dobre nevyzeralo.“ Asi ne; v rozsahu #000000 až #111111 to ostatně ani není možné, tam jsou jen odstíny modré a zelené (pominu-li černou). Gradient barev #000000 až #111111 mimochodem nedává moc smysl, osobně mezi těmito dvěma odstíny nevidím rozdíl: #000000 #111111 Působí-li gradient mezi takovými blízce sousedícími hodnotami pruhovaně či zubatě, může být příčinou jedině nějaký zaokrouhlovací algoritmus nebo jiná nedokonalost výstupního zařízení, ale ne to, co je zakódované v originální grafice – protože zakódovat to lze (šestimístně hexadecimálně) jemněji, než je lidské oko schopno rozlišovat. |
||
Chamurappi Profil |
#23 · Zasláno: 23. 5. 2012, 19:29:32
Reaguji na Petra ZZZ:
„osobně mezi těmito dvěma odstíny nevidím rozdíl“ Pokud jsou takhle oddělené, rozdíl patrný není. Ale když se dají k sobě, tak i uvnitř gradientu složeného ze sedmnácti barev jsou hrany mezi jednotlivými barevnými pruhy viditelné: |
||
_es Profil |
Petr ZZZ:
„To se už ale bavíme o nedokonalosti výstupního zařízení, ne?“ Nie, o existencii možných farieb v 24 bitovom rozlíšení (256 možných zložiek červenej krát 256 z. zelenej krát 256 z. modrej). „v rozsahu #000000 až #111111 to ostatně ani není možné, tam jsou jen odstíny modré a zelené“ Nie, medzi nimi sú len odtiene šedej, ak má byť prechod lineárny - prvé hodnoty z ukážky farieb v [#16], či v obrázku v [#23]. #000000 je čierna #111111 je tmavosivá a medzi nimi je len 16 odtieňov tmavosivej. V 24 bitovom rozlíšení existuje len 256 odtieňov sivej (vrátane bielej a čiernej). Tie ostatné milóny možných farieb sú s nejakým farebným vnemom, teda napríklad nejaký odtieň žltej, červenej, zelenej, fialovej, ... Chamurappi: „i uvnitř gradientu složeného ze sedmnácti barev jsou hrany mezi jednotlivými barevnými pruhy viditelné“ Za čo možno môže aj [#19]. |
||
Petr ZZZ Profil |
Reaguji na Chamurappiho:
Nedalo mi to a zkusil jsem to nakódovat. Říkal jsem si, jestlipak to nebude vypadat jinak než na tvém png – a hm... vypadá to stejně. Skoro stejně – čtvrtý proužek od konce mi na tvém png připadá o něco světlejší než na mé stránce. Ale to jen na okraj, to je nepodstatný detail. Mnohem zajímavější mi přijde, že mezi posledními zhruba třemi až pěti pruhy – jak na tvém png, tak na mé nakódované ukázce, vidím rozdíly, mezi ostatními pruhy ale už ne. Přitom by ty rozdíly měly být plynule odstupňované. Napadlo mě, zda tam "neprobíjí" sousední barvy, tak jsem v horní ukázce přidal ještě okrový proužek a v dolní ukázce na jeho místo černý. Ale horní a spodní ukázka na mé stránce se od sebe neliší. Asi má _es [#19] pravdu a nějak se to uměle zvýrazňuje. Reaguji na _es: Ano, mezi #000000 a #111111 je jen 16 hodnot šedé, ale proč by vlastně měl být přechod nutně lineární? V okamžiku, kdy se vzdáme nároku na lineární přechod, je těch hodnot mezi těmito dvěma hodnotami více než milión, a já trvám na tom, že v rámci tohoto miliónu sousední hodnoty od sebe lidské oko neodliší. Z toho vyplývá, že musí být možné vytvořit plynulý gradient, a pokud to v praxi možné není, může to být jen a pouze nedokonalostí výstupního zařízení, případně tím, o čem píšeš v [#19] – tedy úmyslným zkreslením. U rozsahu #000000 až #111111 se nebavíme o ostatních miliónech barev, nýbrž jen o jednom miliónu – a tam vidím opravdu jen modré a zelené tóny, ostatní vidím až u čísel zřetelně vyšších než #111111. Samozřejmě v čísle např. #110088 je červená obsažena (to jsou ty dvě jedničky), ale vidět tam není, celkový dojem této barvy je modrý s lehounkým nádechem do fialova. :) |
||
_es Profil |
Petr ZZZ:
„Ano, mezi #000000 a #111111 je jen 16 hodnot šedé, ale proč by vlastně měl být přechod nutně lineární? V okamžiku, kdy se vzdáme nároku na lineární přechod, je těch hodnot mezi těmito dvěma hodnotami více než milión, a já trvám na tom, že v rámci tohoto miliónu sousední hodnoty od sebe lidské oko neodliší.“ Ale to by bol trebárs taký prechod medzi farbami, že by to šlo trebárs z čiernej na červenú uprostred prechodu a odtiaľ na tmavosivú - to by asi veľmi nevyzeralo ako prirodzené prelínanie čiernej do tmavosivej - bol by to len prechod s obchádzkou. Gradient farby by bol len vyšší než pri obyčajnom lineárnom gradiente v RGB definícii farby. To je už rozumnejšie použiť ten tzv. dithering ([#5]). „případně tím, o čem píšeš v [#19] – tedy úmyslným zkreslením.“ Je to možné, no nie nutné, ľudský zrak je veľmi citlivý na vnímanie optických gradientov. |
||
Petr ZZZ Profil |
#27 · Zasláno: 25. 5. 2012, 20:05:05
_es:
„trebárs z čiernej na červenú uprostred prechodu“ V rámci všech 16.777.216 barev ano, v rozsahu od #000000 do #111111 ale nic viditelně červeného není. Pokud by se do přechodu mezi dejme tomu dvěma šedými odstíny #030303 a #040404 vložilo několik dalších mírně "barevných", předpokládám, že by oko nic jiného než šedý gradient nevnímalo. Zřejmě zde jde především o to, aby pruhy stejné barvy nebyly příliš široké. Uděláš-li přechod např. #030303 — #030304 — #030305 — #030306 — #030307 — #030308 — #030309, neměly by žádné viditelné pruhy vzniknout a např. #030309 není šedá jen podle číselného kódu – pro oko je to černé nebo tmavošedé, ale ne barevné. |
||
Časová prodleva: 9 dní
|
|||
_es Profil |
Petr ZZZ:
„v rozsahu od #000000 do #111111“ Ako chceš matematicky definovať ten „rozsah“? To môžem prejsť od 000000 do 111111 aj cez 550000, AA0000, FF0000. „Uděláš-li přechod např. #030303 — #030304 — #030305 — #030306 — #030307 — #030308 — #030309, neměly by žádné viditelné pruhy vzniknout“ Ale takému niečomu chýba praktický zmysel, lebo to oveľa lepšie rieši už spomínaný dithering a to bez prímesí cudzích farieb. Okrem toho by zase asi vznikli podivné farebné gradienty pri pohľade z väčšej diaľky. „např. #030309 není šedá jen podle číselného kódu – pro oko je to černé nebo tmavošedé, ale ne barevné.“ Ak by bola v blízkosti tejto farby biela, čierna, či inverzne žltá, tak by nefarboslepý bol schopný rozoznať, že ide o tmavošedomodrú. |
||
Časová prodleva: 4 dny
|
|||
Petr ZZZ Profil |
#29 · Zasláno: 7. 6. 2012, 15:03:25
_es:
„Ako chceš matematicky definovať ten ‚rozsah‘?“ Úplně stejně, jako když počítáš od nuly do jednoho miliónu stoosmnácti tisíc čtyřsetosmdesátijedné (hexadecimálních 111.111 je decimálních 1.118.481). Pokud jde o šedý gradient, bude zapotřebí vyloučit modré a zelené tóny (červené už vyloučeny jsou – jak už jsem dvakrát psal, v daném rozsahu nic červeného není). „To môžem prejsť od 000000 do 111111 aj cez 550000, AA0000, FF0000.“ Nebudu ti v tom bránit, ale mluvím-li o přechodu od nuly do sta, nemám na mysli, že je inkludováno i pět set. :-) |
||
_es Profil |
Petr ZZZ:
„Úplně stejně, jako když počítáš od nuly do jednoho miliónu stoosmnácti tisíc čtyřsetosmdesátijedné (hexadecimálních 111.111 je decimálních 1.118.481).“ Farby sú definované pomocou troch zložiek farieb, teda ide o analógiu trojrozmerného priestoru. Ako chceš 16 777 216 malých kociek vo vnútri veľkej kocky nejako prirodzene usporiadať za sebou? Za #0000FF ide „matematicky“ #000100, no o nejako vnemovo susedné farby určite nejde. Ak medzi dvomi kockami vo veľkej kocke spravíš úsečku a kocky, ktoré pretína, zoradíš za sebou, vtedy sa dá hovoriť o nejakom rozsahu medzi farbami, nie z nejakého chybného pochopenia nejakého binárneho zápisu. „Pokud jde o šedý gradient, bude zapotřebí vyloučit modré a zelené tóny (červené už vyloučeny jsou – jak už jsem dvakrát psal, v daném rozsahu nic červeného není).“ No a keď nebudem považovať za číslo #RRGGBB ale #BBGGRR či #GGBBRR? Prečo by mal byť rozdiel medzi poradím zápisu zložiek farby? Ak všetky „tóny“, a aj všetky ostatné „tóny“ ostatných farieb, vylúčiš, tak dostaneš spomínaných 16 odieňov šedej. |
||
Téma pokračuje na další straně.
|
0