Święta racja, dlatego wymyślono jeszcze inną przestrzeń barw i to dopasowaną już w pełni do ludzkiego oka i nosi ona nazwę CIELAB .... to jest to nad czym teraz z kolei ślęczę

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Wow, Mirku no to wyjdzie z tego jakiś superprogram kolorymetryczno-konwersyjny

Tak Lab jest (chyba 3 wersje są) podobno w ogóle jest tak zaprojektowana, że zawiera wszystkie możliwe kolory jakie człowiek może zobaczyć i ciekawe bo mimo że ma mniej odcieni niż 24bit RGB, to dla człowieka jest jakby pełniejsza. Szukałem kiedyś czegoś w tym zakresie... Jest jakaś biblioteka ColorMine się chyba nazywa i ale nie bardzo mogłem ją znaleźć, albo raczej nie chciała się pobrać.

W ogóle jeszcze w podobnym temacie. To można jeszcze do RGB dopiąć czysty biały czyli RGBW, nawet widziałem takie diody
"czterordzeniowe" fmy Cree... Też by było ciekawe, tylko 4 kanały PWM trzeba dać.

Naprawdę z CIELAB color wystarczą 3 kanały PWM ... ale niestety jak narazie im dalej się w to wgryzam - ty może być gorsza implementacja tego na 8-bitowce niestety .... już po wielu godzinach czytania i dryfowania po bezkresach oceanu załapałem pierwsze algorytmy i kody, z którymi najpierw będę mógł się pobawić na PC ...

Masz rację to co jako PODSTAWOWY ATUT daje CIELAB color to właśnie - ten nasz kochany żółty, którego podczas przewijania kolorów jest prawie BRAK ...

Tzn tematy te są dla mnie mega ciekawe ... tylko jak mówię nie wiem czy sobie dam radę na 8-bitowcach

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Zaczyna się trochę bardziej zaawansowana matematyka, może nie dać się uciec od liczb FLOAT, w obliczenia wchodzą pierwiatski.
Zawsze niby można kosztem większego użycia pamięci wejść w te floaty.
Ale powiem jeszcze takie coś, że jakość koloru bardzo zależy od diody. Taka prosta dioda RGB, w klasycznej obudowie słabo bardzo miesza kolory. Dużo lepsze rezultaty obserwowałem na diodach SMD, np. takich jakie są w taśmach. Ta "inteligentna" dioda której dotyczyła ostatnio zagadka też pewnie prezentuje się bardzo dobrze.
Sam używam takiego 10W potworka na którym ten żółty jest bardzo ładny, bardzo ładne są odcienie pomarańczowe tylko faktycznie w porównaniu z niebieskimi kolorami, przy przewijaniu jest tego znacznie mniej.

To ten "potworek":

ŁAŁ - no to kawał potwora

tak z tym CIELAB to nawet na PC długo trwa korekcja z RGB więc na 8-bitowcach to już byłaby masakra

ale generalnie mam już praktycznie fajnie dopracowaną procedurkę

void hsv_to_rgb( RGB * myrgb, uint8_t h, uint8_t s, uint8_t v);

gdzie nie jest źle nawet z przejściem żółtego ... a jeśli statycznie włączać kolory to też widać i żółty z odcieniami i pomarańczowy ...

będzie GIT

to i tak jest DUUUŻO więcej niż wcześniej gdy człowiek babrał się w ogóle nawet bez zwyklastego Gamma correction

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

myrgb to struktura ?

ja mam takie coś:

Tak tak, to żeby nie podawać dodatkowych 3 argumentówr,g,b

ale mi ta twoja funkcja w ogóle nie działa ciężko mi sprawdzić ...

w mojej hue przekazuje się jako uint8_t i kółko jeździ od 0 do 255 dzięki temu też obliczenia szybciej się wykonują ale pewnie troszkę traci się na dokładności. Tylko nie wiem co się dzieje że gdy podkładam twoje obliczenia to tylko coś mi tam miga dziwnie. Muszę jeszcze popróbować.

------------------------ [ Dodano po: 2 minutach ]

aaa no bo tu już jest babol:



zmienna hue jest u ciebie uint16_t a tymczasem powinna chyba być int

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

ten CIELCh jest faktycznie ciekawy. To jest to chyba mapowanie HSV na LAB. HSV dzięki temu się normalizuje. Myślę, że on jest przez to dokładniejszy w tych kolorach które nie mają pełnego V i S. Czyli mamy bardziej płynne przejścia przy małych nasyceniach i małych jasnościach.

------------------------ [ Dodano po: 4 minutach ]


Tak chyba faktycznie powinna być int bo w tym warunku może wyjść poniżej 0, co prawda natychmiast ją przerzuci z powrotem w zakres dodatni, ale ten moment krótki może coś źle robić.
Co ciekawe u mnie to działa bez problemu...

eeeeh i u mnie już działa sorki miałem głupi błąd - zapomniałem poprawić typu swojej zmiennej hue

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Zmieniłem ten typ na int i chyba coś się zmieniło. Na końcach zakresu była jakby mała nieciągłość a teraz jej nie ma.

ok ja mam tak:



tutaj wszystkie składowe hsv zmieniają się od 0 do 255

------------------------ [ Dodano po: 4 minutach ]

ale są jednak przez to wyraźniejsze skoki PWM podczas przejść między niektórymi kolorami - szczególnie w okolicach żótego

no coś za coś ... wszystko jak widać zleży do czego chcemy użyć takiego przeliczania.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Zaraz spróbuje zrobić nowy projekt i przetestować na tej wielkiej diodzie heheh

a jednak nie - przy powolnym czasie zmiany kolorów - obydwie funkcje zachowują się praktycznie identycznie a więc wychodzi na to że lepiej używać chyba tej lżejszej ... ale jeszcze potestuję..

No i czekam na info jak twój potwór sobie z tym poradzi

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

tak to miałoby ręce i nogi gdyby tak stablicować ... mi się niestety nie udało jak dotąd poszukać dobrych wzorów .... A przydałoby się, żeby je tzn może inaczej żeby na ich podstawie na PC np w MkAvrCalculator móc sobie wystrzelić dowolne tablice i władować je do procka

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No i przetestowane:


Funkcja bardzo ładnie działa, pomyślę jakby to sfilmować tak w ogóle, ale chyba poczekam do wieczora, posprzątam w pokoju i naładuję kamerę HD. Telefon też robi w HD, ale jednak ma słabszą dynamikę więc gorzej to widać będzie. Ta dioda daje bardzo mocno, jest jasno w całym pokoju, a i tak nie jedzie na pełnym prądzie bo jest trochę źle zasilana. Konkretnie przez ULN2003 z dobranym napięciem aby prąd wyszedł około 200mA, przy czym obwód "czerwony" ma dodany rezystor cermetowy kilka ohm bo czerwona LED ma znacznie mniejszy spadek napięcia.
Zakupiłem już do niej drivery prądowe sterowane PWM (1500 mA) tylko, że muszę ruszyć temat płytki PCB bo układziki są SMD.

Funkcja działa praktycznie tak samo jak ta moja. Może przy bardziej powolnych zmianach czasami widać pewną skokowość. Co zapewne jest związane z mniejszą ilością kroków w parametrze H.
Kod był uruchomiony na AT88, zajął 610 B flasza i 4 B RAMu.

sq8dsr ---> łeeeech no twoja wersja działa JEDNAK ZNACZNIE lepiej a dopiero teraz doszedłem .... pewnie z uwagi na dużo większy zakres Hue i to nie jest TROSZKĘ ale dużo lepiej. Co ważne poprawiłem ją znacznie bo bez tego była kicha .. tzn bez rzutowania do UL stałych dosłownych. ..... O kurczę i kolejne odchudznie - można zmienne x_val dać jako uint8_t ... wywalić te pierwsze dwa warunki while() i już się ładniutko robi

------------------------ [ Dodano po: kilkunastu sekundach ]

powiem ci, że spokojnie teraz można wolniej jechać i żółty o wiele dłużej i lepiej widać - co więcej i pomarańczowy się trzyma przez jakiś czas ... jest cacuni że tak powiem

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

hehe, wiesz ona nie jest moja, posiłkowałem się przykładem z netu, coś tam też właśnie zmieniałem jeśli chodzi o typy. Nawet już nie pamiętam bo to było kilka miesięcy temu.

tak samo ta moja nie jest moja - nie ma co się przejmować ja też brałem z netu i przerabiałem po swojemu jeden pies ...

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

A mnie teraz korci, żeby tablicowanie korekcji gamma połączyć z konwersją HSV. W sumie na 256 dyskretnych wartości potrzeba raptem tylko 768 bajtów.

Tzn próbowałem w tej funkcji hsv2rgb() w jej środku używać korekcji gamma ... ale niestety porażka ... ten algorytm hsv jeśli chodzi o Hue sam chyba to robi (no chyba że gdzieś się machnąłem) .... Za to np wartość V czyli sterowanie jasnością jak najbardziej można przepuścić przez gamma correction i tym właśnie posługuję się w ostatnim poradniku w kodzie to rozjaśnianie i ściemnianie na początku które widać - to właśnie V "z" i "bez" korekcji gamma

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Ja bym chciał spróbować zrobić tak:
Stablicować PWM dla RGB w 256 krokach i funkcją hsv2rgb włączać nie kolejne wartości PWM tylko kolejne elementy tablic.
Funkcja sama w sobie raczej nie może mieć korekcji gamma dla HUE bo jest zbyt prosta matematycznie, wzór który jest opisany w tym śmiesznym BASICu na Twoim Blogu, jest dość skomplikowany. Potęgowanie z wykładnikiem typu FLOAT...
Z tego co zaobserwowałem hsv2rgb daje coś jakby wyrównanie odcieni, ale to chyba jest wynikiem samej właściwości przestrzeni HSV. Choć to bardzo zależy od diody. Takie tanie 5mm diody RGB to efekt raczej mizerny. Za to ten potworek którego używam sam w sobie jest jakby bardziej liniowy, a poza tym (podobnie jak takie płaskie diody SMD) lepiej miesza kolory.

No więc dlatego pisałem że gdy próbowałem dodawać gamma correction przy Hue to wychodziła sieczka (tzn gamma dla każdej składowej RGB) .... Ta proporcja i tak jest w miarę dobrze wyliczana przez ten prosty algorytmik ...

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Wiesz co Mirek, zauważyłem jeden problem w tej funkcji HSV_to_RGB. Tzn może nie jest to taki straszny problem, ale jakby jej właściwość. Jasność kolorów ma "góry i doliny". Kolory podstawowe R G B, gdy mają pełne nasycenie, powodują wysterowanie poszczególnych diod RGB PWMem o jakimś wypełnieniu (zależnym od wartości B przekazanej do funkcji). Przy tych kolorach świeci tylko jedna struktura. Ale już kolory pochodne R+G, G+B, B+R dają dwa razy więcej światła ponieważ z tym samym wypełnieniem sterowane są już dwie struktury. Oczywiście czułość oka jest logarytmiczna więc nie jest to tak bardzo odczuwalne, nie mniej jednak trochę to widać. Najbardziej chyba przy czerwonym. Myślę, że ta właściwość powoduje dodatkowe jakby pogorszenie liniowości zmian.

Tak tak widać widać ... dlatego np trochę brzydko wygląda przechodzenie z pośrednich kolorów w pełne ... tzn brzydko ... ale co tu zrobić ? .... Zawsze tym naszym okiem jednak widać, że zmniejsza się jasność przy tych płynnych przejściach gdy wchodzi na chwilę pełny kolor. No ale ten problem związany jest niestety także z tym, że przecież oko inaczej postrzega każdy kolor i do tego jeden widzi lepiej a inny gorzej ... generalnie już sobie kiedyś myślałem, żeby tak np zmniejszać nieco PWM w szczytach zmieszanych kolorów tak żeby jasność sprowadzić na poziom jasności pełnych ale ....

Fajnie byłoby to dopracować ale .... tak sobie myślę - robić to tak trochę w oderwaniu od konkretnego urządzenia to troszkę jak walka z wiatrakami bo jak wiemy zależne jest to także a może nawet przede wszystkim od samych diod LED. A poza tym to nie monitor czy ekran gdzie mamy jako tło kolor CZARNY ....

generalnie bardzo ciekawy to temat ... na razie musiałem go odłożyć niestety z uwagi na kupę innych rzeczy, ale myślę że te profile kolorów CIELAB być może mogłyby tu jakoś pomóc ...

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Witam serdecznie kolegów!
Ponieważ programowaniem zainteresowałem się całkiem niedawno, to postanowiłem odświeżyć ten watek z przed 3-ech lat dotyczący trybów pracy liczników, bo w moim przypadku jest on jak najbardziej aktualny. Związku z tym mam pytanie dotyczące pewnej symboliki oznaczeń w tabeli
trybów pracy PWM 16 bitowego (FastPWM).
Czym różni się pozycja licznika TOP od MAX
W nocie opisowej licznika 0 Atmega 16 czytamy:
„ Najprostszy sposób pracy to tzw. Tryb Normal, przy ustawieniu WGM01:0 = 0. W tym trybie licznik zawsze zlicza przez inkrementowanie, a po osiągnięciu maksymalnej wartości TOP = 0xFF licznik „przekręca się” i resetuje od 0.”

Z kolei w liczniku 1 czytamy:

„ Najprostszy sposób pracy to tzw. Tryb Normal, przy ustawieniu WGM013:0 = 0. W tym trybie licznik zawsze zlicza przez inkrementowanie, a po osiągnięciu maksymalnej wartości MAX = 0xFFFF licznik „przekręca się” i resetuje od 0.”

Z tego opisu wygląda na to, że definicja skrótów TOP i MAX jest taka sama.
Ale z tego opisu pod tabelką tak nie wynika.

„TOP – wartość kończąca zliczanie (np. z rejestruOCR1A, albo stałej).
MAX – osiągnięcie wartości (0xFF).
BOTTOM – osiągnięcie minimum (0x00).
CTC –kasowanie przy zrównaniu (clear timer on compare).”

Może TOP to zrównanie wartości licznika z wartością rejestru, czyli compare, chyba, że wcześniej licznik się przekręcił/zresetował.
Możecie mi to logicznie wytłumaczyć.