Ostatnio do rysowania kulki uzylem tej to metody ze generuje obraz kulki w bitmapie
255x256 pikseli po czym pozniej w procedurze rasteryzacji to 'sampluje' i wyswietlam

powstaje jednak problem jak dokladnie dobrac te wspolrzedne generowania i samplowania
by kulka byla naprawde ladna (bo czesto sie zdarza ze jest np lekko niesymetryczna
albo jest nieco mniejsza niz referencyjny midpoint

chodzi np o to czy ta bitmapa z obrazem powinna miec parzysty czy nieparzysty
rozmiar, albo jak doklanie napisac linijke samplowania

u mnie jest to cos w stylu, ale nie myslalem o tym i to ma wlasnie chyba błedy


float r_inv_128 = 1./R*128.;


for(int j=-R; j<=R; j++)
for(int i=-R; i<=R; i++)
{
SurfaceSample s = ball_picture[ (int)(j * r_inv_128 + 127.5) ][ (int)(i *
r_inv_128 + 127.5) ];

(w sumie jestem zmeczony i nawet nie che mi sie o tym pomyslec, ale jak odpoczne to
trzebbedzie dobrac wartosci

do góry

Dnia Tue, 18 Nov 2014 01:37:39 -0800 (PST), firr napisał(a):

> (w sumie jestem zmeczony i nawet nie che mi sie o tym pomyslec, ale jak odpoczne to
trzebbedzie dobrac wartosci

I koniecznie swoimi przemysleniami sie podziel! Najlepiej w formie kolejnych 20
postow
jeden pod drugim. Juz trzemy kolanami nie mogac sie doczekac.

--
pozdro
R.e.m.e.K

do góry

W dniu wtorek, 18 listopada 2014 11:57:57 UTC+1 użytkownik R.e.m.e.K napisał:
> Dnia Tue, 18 Nov 2014 01:37:39 -0800 (PST), firr napisał(a):
>
> > (w sumie jestem zmeczony i nawet nie che mi sie o tym pomyslec, ale jak odpoczne
to trzebbedzie dobrac wartosci
>
> I koniecznie swoimi przemysleniami sie podziel! Najlepiej w formie kolejnych 20
postow
> jeden pod drugim. Juz trzemy kolanami nie mogac sie doczekac.
>
> --
> pozdro
> R.e.m.e.K

trzyj do woli biedny idioto (powinienes trzec podwojnie bo twoje jakze cenne
jełpoizmy (ktore mz zenują nawet idiotów nie mowiac o sredniakach) powinny ci dac
pewnie drugi sort tarcia)

do góry

"firr" <p...@g...com> wrote in message
news:240cc636-6118-4205-8272-77262b32297f@googlegrou
ps.com...
> W dniu wtorek, 18 listopada 2014 11:57:57 UTC+1 użytkownik R.e.m.e.K
> napisał:
>> Dnia Tue, 18 Nov 2014 01:37:39 -0800 (PST), firr napisał(a):
>>
>> > (w sumie jestem zmeczony i nawet nie che mi sie o tym pomyslec, ale jak
>> > odpoczne to trzebbedzie dobrac wartosci
>>
>> I koniecznie swoimi przemysleniami sie podziel! Najlepiej w formie
>> kolejnych 20 postow
>> jeden pod drugim. Juz trzemy kolanami nie mogac sie doczekac.
>>
>> --
>> pozdro
>> R.e.m.e.K
>
> trzyj do woli biedny idioto (powinienes trzec podwojnie bo twoje jakze
> cenne jełpoizmy (ktore mz zenują nawet idiotów nie mowiac o sredniakach)
> powinny ci dac pewnie drugi sort tarcia)

Akurat ma rację, "profesorze"... Nie rozpoczynaj nowych wątków
na ten sam temat tylko kontynułuj w tym samym odpisując
na swoją wiadomość.

do góry

W dniu wtorek, 18 listopada 2014 10:37:40 UTC+1 użytkownik firr napisał:
> Ostatnio do rysowania kulki uzylem tej to metody ze generuje obraz kulki w bitmapie
255x256 pikseli po czym pozniej w procedurze rasteryzacji to 'sampluje' i wyswietlam
>
> powstaje jednak problem jak dokladnie dobrac te wspolrzedne generowania i
samplowania by kulka byla naprawde ladna (bo czesto sie zdarza ze jest np lekko
niesymetryczna albo jest nieco mniejsza niz referencyjny midpoint
>
> chodzi np o to czy ta bitmapa z obrazem powinna miec parzysty czy nieparzysty
rozmiar, albo jak doklanie napisac linijke samplowania
>
> u mnie jest to cos w stylu, ale nie myslalem o tym i to ma wlasnie chyba błedy
>
>
> float r_inv_128 = 1./R*128.;
>
>
> for(int j=-R; j<=R; j++)
> for(int i=-R; i<=R; i++)
> {
> SurfaceSample s = ball_picture[ (int)(j * r_inv_128 + 127.5) ][ (int)(i *
r_inv_128 + 127.5) ];
>
> (w sumie jestem zmeczony i nawet nie che mi sie o tym pomyslec, ale jak odpoczne to
trzebbedzie dobrac wartosci

to jest o tyle ciekawy problem ze jest czy tez moze byc jakby otwarciem na swiat
grafiki z subpikselową precyzją (jak na razie robie tylko nieprecyzyjną grafe)

wiec jak to w sumie powinno byc? czy kulka powinna dotykac brzegami brzegu bitmapy?
(Z tymi floatowymi wartosciami od 0.0 do 1.0 mam ten problem ze 1.0 praktycznie
mapowaloby sie na 256 a to jest poza zakresem bajta - w praktyce wiec robie
(int)(255.9*f) co wydaje sie
troche niedoskonale teoretycznie, ale w
sumie jest chyba poprawne (choc powinno byc pewnie raczej 255.9999 ale z kolei moze
nie 255.99999999999999 mam nadzieje ze jakies reguly przyblizen na floatach nie
zaokreglily tego kiedys do 256.)
To sa w sumie jakies ciezkie detale tej
arytmetyki przyblizen/bledow i zaokraglen na floatach choc na intach tez to wystepuje
nie wiem czy warto temu poswiacjac wiecej uwagi

przechodzac do bitmapy kulki i wzorku jej probkowania: pewnie i tak mozna traktowac
kulke jako kolke o promieniu 1.0, przy wypelnianiu bitmapy zrobic dokladne
probkowanie dla srodkow pikseli

cd za chwile

do góry

>
> przechodzac do bitmapy kulki i wzorku jej probkowania: pewnie i tak mozna traktowac
kulke jako kolke o promieniu 1.0, przy wypelnianiu bitmapy zrobic dokladne
probkowanie dla srodkow pikseli
>

czyli
for(int j=0; j<256; j++)
for(int i=0; i<256; i++)
{
float x = .5 + i - 128.;
float y = .5 + j - 128.;
}

poprawnie?
dla x = 128 jest .5 ok

cwiartka ma 128 pikseli ostatnim pikeslem jest 127 czyli 255 wartosc 127.5 chyba ok

w ujemną strone pierwszym pikselem jest -1 czyli 127 dostajemy -.5 ok
dla piksela nr zero jest -127.5

jest ok

teraz dalsza czesc zagadnienia

do góry

>
> teraz dalsza czesc zagadnienia


skalowanie

problemem jest juz chocby to jak wysamplowac ta kulke jednym punktem,
ktory piksel przeczytac? .0 .0 daje lewy gorny z tych czterech po srodku (zlamanie
symetrii i zly rezultat, jako ze ten piksel juz ma normalną troche odcholona w orawo
i w gore)

samplowanie dwoma punktami - zakladam ze wzorek na to chyba by mial taka postac jak
nalozenie upskalowanego 1x2 pikselowego okienka na to nasze 256x256 pikselowe czyli
koordynaty defakto
64. 64. 192.64
192. 64. 192.192.
i tez są błady decyzji przy wyborze piksela, tak samo nowet dla 3x3
tak samo dla 4x4, dopiero dla 5x5 gdzie ekran dzieli sie na 10 tke dostajemy
25.6 + i*51.2 i wtedy bledy samplowania
zmieniaj sie chyba na nieco inne (bedą odchyly dla dziesietnych końcówek ale chyba
przynajmniej beda symetryczne, w kazdym razie tez chyab wyglada na to ze
takiego 25.6 nie nalezy tez castowac tylko zaokraglac (zeby zmniejszyc blad typu
0-0.999 na blad skali 0.499)

w kazdym razie juz z tego widac ze cos tu jest nie tak i ze chyba nalezaloby to
wszystko poprawic

do góry

>
> w kazdym razie juz z tego widac ze cos tu jest nie tak i ze chyba nalezaloby to
wszystko poprawic

kwestie: 1) jest nieparzyste wygenerowanie bitmapy (a jesli wygenerowania
nieparzyscie to i defakto nieparzysta w rozmiarze) jedyną praktyczną opcją?
2) co zrobic by cala procedura byla (int) cast friandly - czy tez nic nie robic ?

na dany moment nieparzysta bitmapa wydaje mi sie chyab jedyną opcją (choc nie jestem
pewien), [jest to chyba w niejakiej sprzecznosci z kiedys uzyskana przeze mnie
odpowiedzą gdy spytalem gdziec czy sprity maja byc parzyste czy nieparzyste (ktos
sugerowal ze parzyste))

do góry

W dniu piątek, 5 grudnia 2014 14:37:09 UTC+1 użytkownik firr napisał:
> >
> > w kazdym razie juz z tego widac ze cos tu jest nie tak i ze chyba nalezaloby to
wszystko poprawic
>
> kwestie: 1) jest nieparzyste wygenerowanie bitmapy (a jesli wygenerowania
nieparzyscie to i defakto nieparzysta w rozmiarze) jedyną praktyczną opcją?
> 2) co zrobic by cala procedura byla (int) cast friandly - czy tez nic nie robic ?
>
ok, skoro tak to trzeba przemyslec nieparzystą wersje
srodek piksela 128, 128 odpowiadalby .0 .0,
piksel 255 odpowiadalby 127.
piksel 1, -127.0
ktoras kolumne trzeba wywalic albo pierwsza albo ostatnią, ciezka decyzja moze jednak
lepiej wywalic ostatnią
(czyli jednak srodkowy piksel bylby w 127 127)

jak teraz wpisac kule w ta bitmape 255x255, tez chyba mozna tak brzegowo

z drugiej strony gdyby ktos kiedys chcial probkowac sume po kilku pikselach moglby to
przeszkadzac choc w sumei mozna sobie dodac puste wirtualnie choc czasem fizyczne
wygodniej

to jak wpisac ta kulke moze byc brzemiennw w wynik bo jesli ktos by
rasteryzowal jakas ta wpisana brzegowo
to mzoe kiedys ten jeden punk moglby tam wystawac (acz nie chce mi sie zastanawiac
kiedy, pozatym cos chyba daloby sie z tym jednak zrobic) - moze wiec powinienem ja
tam wpisac regułą 255.99 ?
idealne sprobkowanie z drugiej strony mialoby elegancje tablicy matematycznej
wiec moze jednak to, kula o promieniu
127.5 (i tak jakos to malo matematyczne)
- teraz trzeba by sie zastaniowic jakby dzialal sampling


255

do góry

> - teraz trzeba by sie zastaniowic jakby dzialal sampling
>

wydaje mi sie ze w tej nieparzystej wersji
dzialalby z grubsza okay

problem jest jednak ciag;e taki ze i tutaj mozna by czasem trafić ze wspolrzedną
miedzy piksele - wtedy poniewaz kulka jest symetryczna a wybieranie pikseli jest
ukierunkowane np na zawsze lewy w gore - wystapily by bledy i kulkabybyla
niesymetrycznie snieksztalcona - lepiej bybylo przyblizac np zawsze do srodka lob
zawsze na zewnatrz to zachowywaloby ksztalt
- ale ciezsze (jesli nie ciezkie, do zakodowania - moze jednak wystarczy uzyc tylko
floor a math.h -pozniej zobacze

inan kwestia dla ilu skalowań dla dyskretnych srednic 1,2,3... takie cos by wystapilo
(nie chce mi sie liczyc),
chyba jednak nei dla za wielu

widac jednak jak taki niby prosty problem ma zakamarków

daej nalezyaloby przemyslec kwestie tego czy uzywac tez floatowych promieni przy
rysowaniu i czy uzywac floatowych wspolrzednych przy rysowaniu (i czy
uwzgledniac je w tym mapowaniu - to jeszcze nie jest antyaliasing

(dalej jest kwestia antyaliasingu brzegowego,
antyaliasking wiaze sie jednak ze swoistymi problemami

1) niejasna dla mnie kwestia jak dodawac kolory
2) obnizenie wydajnoci na ustalenie wspolczynika f (tego glownego 0. do 1.)
3) straszna kwestia nielinearnej luminancji
4) kwestia wyraznie zwiekszonego storage
na trzymanie klatki (filmu)
5) kwestia znacznie obnizonej wydajnosci na przekonwertowanie obrazu do wyjsciowego
rgb

(o ile wogole czegos nie ominalem, ale ogolnie nieststy spodziewam sie wyraznego
slowdownu i ew frustrujacych klopotow zwiazanych z tym by naprawde tą gamme zrobic
dobrze i o tyle nie che mis ie za to zabierac - gdyby tak procki bylu z 10 razy
szybsze to co innego)

do góry