ATNEL tech-forum

Re: MkAVRcalculator generator korekcji gamma PWM

2014-06-24T00:01:01+01:00

CIELab też jest opisany w trzech prostopadłych wymiarach (ale jest to nieregularna bryła).

Chodzi o to że posługując się modelem CIElab i wędrując w przestrzeni trójwymiarowej CIElab(po tym wektorze) ze stałą prędkością płynnie zmieniamy barwy.

Nie można tego powiedzieć o poruszaniu się w przestrzeni RGB.
Innymi słowy każdy wektor w przestrzeni RGB charakteryzuje różna i nielinowa zależność pomiędzy szybkoscią poruszania na wektorze a szybkością subiektywnego odczucia zmiany barwy.

W tym poście używałem już zdań twierdzących ale nie jestem specjalistą więc może ktoś inny to wyjaśni lub potwierdzi

Jeżeli jesteśmy w modelu RGB to nie trzeba być mistrzem algebry
np przechodząc z 0x0016FF do 0x0026DF

wystarczy niezależnie liniowo zmieniać każdy kanał czyli (oczywiście częstotliwości zmiany każdego kanału mogą i zapewne będą się róźnić)
00 -> 00
16 -> 26
FF -> DF
wtedy mamy ten wektor

Albo jeszcze prościej, szukamy sobie wzoru na prostą w układzie (x,y,z) przechodząca przez 2 dane punkty x1,y1,z1 i x2,y2,z2 i jedziemy po tej linii.
Najprościej było by posłużyć się przedstawieniem prostej opartej na rzutach na płaszczyzny 0xy i 0xz czyli
(x,ax+b,cx+d)
Równania liniowe ax+b i cx+d mamy ze wzoru:
(y-y1)*(x2-x1)=(y2-y1)*(x-x1)

Przy CIElab trzeba by w między czasie zrobić 2 konwersje pomiędzy RGB a CIElab tak żeby poruszać się po tym wektorze w przestrzeni CIElab(na tym nam zależy) i żeby móc to wyświetlać na diodzie z kanałami RGB.

Statystyki: Napisane przez Wojtek001 — 24 cze 2014, o 00:01

Re: MkAVRcalculator generator korekcji gamma PWM

2014-06-23T23:51:17+01:00

HSV jest modelem opartym o stożek. Wszystkie normalne przejścia będą w jakimś stopniu krzywymi stożkowymi.
Zagadnie które poruszasz jest bardzo ciekawe. W sumie to może wystarczy tu model RGB. (CIE będzie lepszy bo uwzględnia kwestie psychopercepyjne). W RGB mamy sześcian i w tym sześcianie (traktowanym jako przestrzeń wektorowa) można określić wektory,(przebiegające w dowolnych kierunkach wewnątrz sześcianu) które będą przejściami płynnymi między jednym a drugim kolorem.
Nie jestem mistrzem algebry niestety, trzeba by sobie kilka rzeczy przypomnieć...
Niestety czuję, że może to wymagać trochę RAMu, być może trzeba by taki sześcian jakoś w pamięci reprezentować. 24 bitowy kolor raczej odpada bo to jest 256^3 punktów.

Statystyki: Napisane przez sq8dsr — 23 cze 2014, o 23:51

Re: MkAVRcalculator generator korekcji gamma PWM

2014-06-23T23:16:57+01:00

Tak jak pisze, używałem już HSV(+gamma na to) ale z użyciem HSV nie dało się uzyskać płynnego przejścia pomiędzy złożonymi barwami np. pomarańcz -> fiolet

CIElab (+ gamma na to) zdaje się daje taką możliwość ,bo wyczytałem:
Transformację tę wprowadzono w wyniku badań nad spostrzeganiem
przez oko ludzkie różnic między barwami. Różnica pomiędzy dwiema barwami
w przestrzeni Lab ma postać:
DE = sqrt((DL)2 + (Da)2 + (Db)2)
i jest odległością euklidesową pomiędzy dwoma punktami w przestrzeni trójwymiarowej.

teraz kwestia czy jest to rzeczywiście zauważalne dla diody RGB. Oczywiście nie zamierzałbym tego liczyć w mikro kontrolerze ale stablicować gradienty.

Statystyki: Napisane przez Wojtek001 — 23 cze 2014, o 23:16

Re: MkAVRcalculator generator korekcji gamma PWM

2014-06-23T23:07:03+01:00

Wojtek001 napisał(a):

Więc CIElab nie zastąpi korekcji GAMMA ? Dobrze to rozumiem?

Korekcja gamma koryguje nieliniową charakterystykę świecenia diod.
HSV w połączeniu z tablicowaniem wartości PWM przez korekcję gamma daje bardzo dobre rezultaty.

Statystyki: Napisane przez sq8dsr — 23 cze 2014, o 23:07

Re: MkAVRcalculator generator korekcji gamma PWM

2014-06-23T22:20:41+01:00

Co do profilów barw to ja na razie tylko z konwersją HSV->RGB się bawiłem ,bo chciałem płynnie przelecieć po wszystkich barwach (składowa hue o 360).

Model CIElab miałby służyć do generowania jak najbardziej płynnego przejścia pomiędzy dwoma dowolnymi brawami?
(np korekcja GAMMA pozwala na ładne przejście pomiędzy jasnym zielonym a ciemnym zielonym ale jeśli chcemy mieć ładne przejście między pomarańczem a fioletem(używając wszystkich kanałów RGB) to musimy jeszcze użyć CIElab)

Tylko jak przeprowadzimy transformacje CIElab -> RGB to i tak chyba na to RGB musimy nałożyć korekcje gamma?
czyli tak by to można ująć?
CIElab -> RGB -> GAMMA(R)+GAMMA(G)+GAMMA(b)

Więc CIElab nie zastąpi korekcji GAMMA ? Dobrze to rozumiem?

Statystyki: Napisane przez Wojtek001 — 23 cze 2014, o 22:20

Re: MkAVRcalculator generator korekcji gamma PWM

2014-06-23T21:02:04+01:00

aaa zebrało się już kilka poprawek łącznie z tą gamma - więc już można zassać build 65

Statystyki: Napisane przez mirekk36 — 23 cze 2014, o 21:02

Re: MkAVRcalculator generator korekcji gamma PWM

2014-06-23T20:56:41+01:00

Dzięki

Statystyki: Napisane przez Wojtek001 — 23 cze 2014, o 20:56

Re: MkAVRcalculator generator korekcji gamma PWM

2014-06-23T20:35:58+01:00

Wojtek001 napisał(a):

Na powyższym wzorze widać że wynik są zawsze zaookrąglane w dół (INT).
Natomiast to co jest w mkavrcalculator zaokrągla zgodnie ze zwykłymi zasadami zaookrąglania przez co w istocie współczynnik gamma jest przeszunięty w dół (gamma=2.5 schodzi do ok 2.35) - jest zauważalnie niżej niż to co używa maxim.

Masz rację .... i sokole oko w tym sensie, że chciało ci się to sprawdzić

Wojtek001 napisał(a):

I teraz mój problem: Czy jest lepiej jeśli używa się takiego zaookrąglania jak Mirek? Jeśli tak to dlaczego (nie wiem, może było to celowe)?

celowe nie było - ot po prostu zwykłe rąbnięcie i użycie właśnie funkcji zaokrąglającej tradycyjnie zamiast obcinającej to co po przecinku

Wojtek001 napisał(a):

Pytam bo nie wiem jak to liczyć.

zastanów się - jakie to ma tak na prawdę znaczenie .... ?

tzn najlepiej weź sobie diodę albo diody LED (na pojedynczej przy rozjaśnianiu i ściemnianiu musiałbyś chyba być matrixem albo jeszcze lepszym niż on, żeby wychwycić różnicę tzn TAKĄ MAŁĄ różnicę w pochyleniu krzywej gamma

Jest to praktycznie kompletnie niezauważalne dla oka ...

oczywiście jeśli sam chcesz to liczyć to co za problem zrobić to wg wzoru maxima ? albo co za problem dodać jakieś własne modyfikacje ? ... nie ma że to ZAWSZE BĘDZIE NAJLEPSZE

zamiast teoretyzować zrób próby na żywym organizmie - przypatrz się sam, poobserwuj, zobacz jaki to ma wpływ.... Ja różnice w krzywej gamma byłem w stanie zauważyć dopiero przy długim pasku gęsto usianych diod LED gdzie jasność jednego koloru zmniejszamy liniowo gradientem .... z tym, że różnice dawało się zaobserwować gdy współczynnik gamma zmieniał się o dość ogromną wartość czyli np o 1 albo więcej niż jeden ....

a tu mówisz o różnicy 2,5 do 2,35 .... konia z rzędem stawiam temu kto szczególnie przy pojedynczej diodzie LED zauważy taką różnicę własnym okiem

Poza tym jeśli chodzi o MkAvrCaluclator i to wbudowane narzędzie to masz tam suwak, którym możesz w pełni płynnie zmieniać krzywą wg totalnie własnego upodobania a co za tym idzie możesz sobie wręcz obserwować zmiany ON LINE jeśli wyniki będziesz od razu wgrywał do procka (tablice) ... i dopasowywał do własnych potrzeb wg własnego uznania

bo i tak GAMMA jak wiesz - o ile widziałeś na blogu ten mój poradnik nie jest akurat na dzisiaj NAJLEPSZYM sposobem do korekcji kolorów - są lepsze algorytmy - chociażby CIELAB .... ale praktycznie nie do zaimplementowania na 8-bitowcu i ciężkie do stablicowania ... a i tak gdyby je zastosować nawet na ARM to sens byłby tylko wtedy gdybyś miał robić kalibrację jakiegoś np monitora/wyświetlacza a nie tam pojedynczych diod LED czy nawet w jakimś prostym matrycowym wyświetlaczu bo do tego wystarczy nawet byle kulawa GAMMA .... nawet ręcznie rozpisana tablica bez obliczeń wg tego wzoru ...

Reasumując - tak jak pisałem na początku - oczywiście masz rację - że powinienem był tam obcinać a nie zaokrąglać i oczywiście dla porządku w aktualizacji programu już będzie tak jak we wzorze maxima więc zachowaj sobie starszą wersję programu i później porównaj na żywych LED'ach że tak powiem na ile się to zmieniło w praktyce .... bo w teorii widać różnicę ale patrząc wręcz na liczby w tablicy - dobrze się przyglądając - a oko nawet nie wyłapie różnicy w krzywej

------------------------ [ Dodano po: 8 minutach ]

Wojtek001 napisał(a):

2) Jaki jest sens wymuszania żeby 0 było tylko na pierwszej pozycji?

widzę że edytowałeś post i doszło pytanie więc podpowiadam

tzn znowu podpowiedziałbym - że lepiej sprawdź w praktyce jaki to ma sens niż teoretyzuj - bo to chyba nie problem podłączyć jedną diodę LED do procka i zrobić jej ściemnianie i rozjaśnianie byle sprzętowym PWM'em - zgodzisz się ?

a skoro tak - to OD RAZU SAM ODPOWIEDZIAŁBYŚ SOBIE NA TO PYTANIE

ale ok zakładam że nie masz procka pod ręką i diody LED to ci podpowiem ... sens jest taki, że przy niskich wartościach PWM np 8-bitów ... te zera na początku - a bywa ich sporo w zależności od pochylenia krzywej - dają czasem przykry efekt dłuższego wygaszenia diody niezgodnego ze stałą czasową jaką przyjąłeś sobie do czasu jej ściemniania i rozjaśniania. Prościej mówiąc efekt jest taki że wydaje się że dioda gaśnie na dużo dłużej, tak jakbyś tam dał specjalnie dłuższy czas. Ale też da się to zauważyć w efekcie komety (czy tam węża) z poradników. Przy tych zerach będzie on po prostu bezczelnie krótszy panie kolego i to jego długość będzie się zmieniać wraz ze zmianą współczynnika gamma. A gdy uzupełnisz jedynkami to długość będzie dla oka taka sama

za to gdy uzupełnimy te zera jedynkami przy zwykłym ściemnianiu i rozjaśnianiu pojedynczej diody LED .... a tylko pierwsza wartość pozostanie zerem - zaczyna to być przyjemne dla oka i równomierne przejścia pomiędzy MAX i MIN. Dlatego dałem taką możliwość w programie a skorzysta z niej ten kto chce po prostu mieć więcej możliwości lepszego dopasowania efektów na diodach do swoich potrzeb. To są właśnie takie moje proste modyfikacje i propozycje usprawnienia sobie pracy z diodami na co dzień

------------------------ [ Dodano po: 11 minutach ]

O, właśnie skompilowałem z obcinaniem wartości po przecinku i już w kolejnej wersji będą ci się zgadzać wyniki podane z MkAvrCalculatora z tablicą podaną przez ciebie z Maxima

Statystyki: Napisane przez mirekk36 — 23 cze 2014, o 20:35

MkAVRcalculator generator korekcji gamma PWM

2014-06-23T19:33:23+01:00

Mam pytanie na temat generartora tablic do pwm'a wbudowanego w program mkavrcalcultor.

Algorytm wbudowany w ten program liczy dane ze wzoru podanego przez maxima:
[syntax=basic4gl]dcyval = INT(width*(((width/arraysize*(index+1))/width)^gamma))[/syntax]

Na powyższym wzorze widać że wynik są zawsze zaookrąglane w dół (INT).
Natomiast to co jest w mkavrcalculator zaokrągla zgodnie ze zwykłymi zasadami zaookrąglania przez co w istocie współczynnik gamma jest przeszunięty w dół (względem tego co jest wyświetlone w oknie programu :gamma=2.5 schodzi do ok 2.35) - jest zauważalnie niżej niż to co używa maxim.

maxim podaje też przykładową tablice (ja też taką wygenerowałem w konsoli dla poniżyszch danych i okazuje się że mamy tu jednak zaookrąglanie w dół):
[syntax=basic4gl]Gamma array size: 64
Total PWM steps: 256
Gamma correction: 2.5

0, 0, 0, 0, 0, 0, 1, 1, 1, 2,
3, 3, 4, 5, 6, 8, 9, 10, 12, 13,
15, 17, 19, 22, 24, 26, 29, 32, 35, 38,
41, 45, 48, 52, 56, 60, 65, 69, 74, 79,
84, 89, 94,100,106,112,118,124,131,138,
145,152,159,167,175,183,191,200,208,217,
227,236,246,256[/syntax]

I teraz mój problem: 1) Czy jest lepiej jeśli używa się takiego zaookrąglania jak Mirek? Jeśli tak to dlaczego (nie wiem, może było to celowe)?
Pytam bo nie wiem jak to liczyć.
2) Jaki jest sens wymuszania żeby 0 było tylko na pierwszej pozycji?

Statystyki: Napisane przez Wojtek001 — 23 cze 2014, o 19:33