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