On 2009-03-31 13:05:14 +0200, Janko Muzykant <j...@w...pl> said:

>> Mam wrażenie, że trochę sobie przeczysz - masz mało danych wejściowych,
>> więc i tak je musisz zinterpolować. Czy zrobisz to (przykładowo) razy
>> 4, czy razy 8, to i tak jest to sztuczna naliczana precyzja. Być może w
>> sytuacjach jakie opisujesz, faktycznie tak jest, ja szczęśliwie
>> sporadycznie muszę dłubać w takim kiepskim materiale, ale kobieca
>> intuicja poparta jakimś tam jednak doświadczeniem podpowiada mi, że to
>> może być kwestia metod, jakimi dłubiesz w fotach.
>
> Najlepiej wyobrazić sobie coś takiego - mamy do policzenia długi ciąg
> działań - z tych prostych - mnożenie, dzielenie, jakiś pierwiastek. No
> i starujemy równo z kalkulatorem ośmiopozycyjnym i dwunastopozycyjnym.
> W zależności od argumentu początkowego i stopnia skomplikowania owych
> działań wynik może różnić się odrobinę (albo nawet wcale) lub bardzo.

A na końcu i tak w obu przypadkach trzeba wynik sprowadzić do 8
pozycji, więc całą dokładność diabli wezmą, bo ulegnie takiemu czy
innemu zaokrągleniu. Z analogią do 8 vs 16 bitów jest jeszcze ten
problem, że ten kalkulator 12-pozycyjny, ma wyświetlacz tylko na 8
pozycji, więc efektów nijak (no prawie, jest jeszcze histogram) nie da
się podejżeć w trakcie, trzeba wierzyć że one tam są.


>>> Widać to na zdjęciach pozornie monochromatycznych (zdjęciach kolorowych
>>> z lat siedemdziesiątych na polskich papierach). No i gratis dostajemy
>>> możliwość bezkarnej wielokrotnej korekty ''wstecznej'' czyli możliwość
>>> przesuwania równowagi kolorystycznej w obie strony.
>>
>> A nie lepiej pracować na warstwach? ;-)
>
> Dużo wolniej.
> Sposób pracy - szeregowej (to co zwykle robię) i równoległej (warstwy)
> przypomina mi trochę ideę wykonywania poleceń w asemblerze w
> komputerkach przemysłowych. Wyszło, że szeregówka jest mi bliższa sercu
> i efektywniejsza.

No to poniekąd wyjaśnia potrzebę większej ilości bitów. Przy pracy, jak
to nazywasz równoległej nie ma potrzeby wielokrotnie machania w te i
wew te suwaczkami, bo można prosto i wygodnie wrócić do któregoś
wcześniejszego przekształcenia i je zmodyfikować. Co koniec końców daje
mniej destruktywną obróbkę, bez wychodzenia poza 8 bitów. I to widać (w
praktyce). I nie specjalnie jest wolniej, choć pewne operacje wymagają
1-2 kliknięć więcej. Dają za to możliwości niedostępne (lub wymagające
nie lada gięcia się) przy obróbce, jak to nazywasz - szeregowej.

--
Pozdrawiam
de Fresz

do góry

de Fresz pisze:
>> Najlepiej wyobrazić sobie coś takiego - mamy do policzenia długi ciąg
>> działań - z tych prostych - mnożenie, dzielenie, jakiś pierwiastek. No
>> i starujemy równo z kalkulatorem ośmiopozycyjnym i dwunastopozycyjnym.
>> W zależności od argumentu początkowego i stopnia skomplikowania owych
>> działań wynik może różnić się odrobinę (albo nawet wcale) lub bardzo.
>
> A na końcu i tak w obu przypadkach trzeba wynik sprowadzić do 8 pozycji,
> więc całą dokładność diabli wezmą, bo ulegnie takiemu czy innemu
> zaokrągleniu.

Ależ skąd - gdy wielokrotnie będziemy jeździć po rzędach wielkości wynik
może być bardzo różny, co wynika z chwilowego przechowywania argumentu z
niską dokładnością.

> Z analogią do 8 vs 16 bitów jest jeszcze ten problem, że
> ten kalkulator 12-pozycyjny, ma wyświetlacz tylko na 8 pozycji, więc
> efektów nijak (no prawie, jest jeszcze histogram) nie da się podejżeć w
> trakcie, trzeba wierzyć że one tam są.

Nie chodzi o podgląd tylko o dokładność przechowywania wyniku
pośredniego. Stąd także ma to sens przy źródłach ośmiobitowych.

>> Sposób pracy - szeregowej (to co zwykle robię) i równoległej (warstwy)
>> przypomina mi trochę ideę wykonywania poleceń w asemblerze w
>> komputerkach przemysłowych. Wyszło, że szeregówka jest mi bliższa
>> sercu i efektywniejsza.
>
> No to poniekąd wyjaśnia potrzebę większej ilości bitów. Przy pracy, jak
> to nazywasz równoległej nie ma potrzeby wielokrotnie machania w te i wew
> te suwaczkami, bo można prosto i wygodnie wrócić do któregoś
> wcześniejszego przekształcenia i je zmodyfikować. Co koniec końców daje
> mniej destruktywną obróbkę, bez wychodzenia poza 8 bitów. I to widać (w
> praktyce). I nie specjalnie jest wolniej, choć pewne operacje wymagają
> 1-2 kliknięć więcej. Dają za to możliwości niedostępne (lub wymagające
> nie lada gięcia się) przy obróbce, jak to nazywasz - szeregowej.

Znam oba sposoby pracy, ale po prostu szeregowy jest dla mnie bardziej
intuicyjny i szybszy. Fakt, z tego powodu bardziej potrzeba 16 bitów,
niż w pracy na warstwach.

--
pozdrawia Adam
różne takie tam: www.smialek.prv.pl
/tak, proszę państwa, wygląd też się liczy.../

do góry

On Tue, 31 Mar 2009 13:16:47 +0200, de Fresz <d...@n...o2.pl>
wrote:

>A na końcu i tak w obu przypadkach trzeba wynik sprowadzić do 8
>pozycji, więc całą dokładność diabli wezmą, bo ulegnie takiemu czy

4 razy 1/4=1, tak?

No to liczymy, w postaci dziesiętnej, jedno miejsce znaczące. W
zależności jak zaokrąglimy to wychodzi:

0,2 + 0,2 + 0,2 + 0,2 = 0,8 lub
0,3 + 0,3 + 0,3 + 0,3 = 1,2.

Dwa miejsca:

0,25 + 0,25 + 0,25 + 0,25 = 1,0.

Wiesz już czemu?
--
Grzegorz Krukowski

do góry

On 2009-03-31 14:07:26 +0200, Grzegorz Krukowski <r...@o...pl> said:

>> A na końcu i tak w obu przypadkach trzeba wynik sprowadzić do 8
>> pozycji, więc całą dokładność diabli wezmą, bo ulegnie takiemu czy
>
> 4 razy 1/4=1, tak?
>
> No to liczymy, w postaci dziesiętnej, jedno miejsce znaczące. W
> zależności jak zaokrąglimy to wychodzi:
>
> 0,2 + 0,2 + 0,2 + 0,2 = 0,8 lub
> 0,3 + 0,3 + 0,3 + 0,3 = 1,2.
>
> Dwa miejsca:
>
> 0,25 + 0,25 + 0,25 + 0,25 = 1,0.
>
> Wiesz już czemu?

A teraz pokaż to na zdjęciach. Bo w teoretycznym modelu matematycznym
wszystko cacy, tylko ja chcę to ZOBACZYĆ.


--
Pozdrawiam
de Fresz

do góry

On 2009-03-31 13:55:39 +0200, Janko Muzykant <j...@w...pl> said:

>> A na końcu i tak w obu przypadkach trzeba wynik sprowadzić do 8
>> pozycji, więc całą dokładność diabli wezmą, bo ulegnie takiemu czy
>> innemu zaokrągleniu.
>
> Ależ skąd - gdy wielokrotnie będziemy jeździć po rzędach wielkości
> wynik może być bardzo różny, co wynika z chwilowego przechowywania
> argumentu z niską dokładnością.

Pozostaje pytanie: jak różny? Ile to będzie, 1%? 2%? 5%?


>> Z analogią do 8 vs 16 bitów jest jeszcze ten problem, że ten kalkulator
>> 12-pozycyjny, ma wyświetlacz tylko na 8 pozycji, więc efektów nijak (no
>> prawie, jest jeszcze histogram) nie da się podejżeć w trakcie, trzeba
>> wierzyć że one tam są.
>
> Nie chodzi o podgląd tylko o dokładność przechowywania wyniku
> pośredniego. Stąd także ma to sens przy źródłach ośmiobitowych.

Pod warunkiem, że na koniec da się zobaczyć różnicę. A nie zawsze/każdy
da radę ją zobaczyć, m.in. z racji konieczności interpolacji w dół na
samym końcu, która, jak to zwykle bywa, też jest obarczona pewną
niedokładnością i wymaga uśrednień.


>> No to poniekąd wyjaśnia potrzebę większej ilości bitów. Przy pracy, jak
>> to nazywasz równoległej nie ma potrzeby wielokrotnie machania w te i
>> wew te suwaczkami, bo można prosto i wygodnie wrócić do któregoś
>> wcześniejszego przekształcenia i je zmodyfikować. Co koniec końców daje
>> mniej destruktywną obróbkę, bez wychodzenia poza 8 bitów. I to widać (w
>> praktyce). I nie specjalnie jest wolniej, choć pewne operacje wymagają
>> 1-2 kliknięć więcej. Dają za to możliwości niedostępne (lub wymagające
>> nie lada gięcia się) przy obróbce, jak to nazywasz - szeregowej.
>
> Znam oba sposoby pracy, ale po prostu szeregowy jest dla mnie bardziej
> intuicyjny i szybszy. Fakt, z tego powodu bardziej potrzeba 16 bitów,
> niż w pracy na warstwach.

Ot, degustibusy. W każdym razie zaczynam rozumieć skąd te ciągoty wśród
wielu fotografująch do fyfnastu bitów. Bo obserwacje - choćby tutoriali
dostępnych w necie, wykazują dziwną niechęć społeczeństwa do używania
małodestruktywnej obróbki "równoległej" (spodobało mi sę to określenie,
dodać (C)? ;-).

--
Pozdrawiam
de Fresz

do góry

at Mon 30 of Mar 2009 15:25, de Fresz wrote:

> On 2009-03-30 11:51:35 +0200, Janko Muzykant <j...@w...pl>
> said:
>
>>>> Do kręcenia kolorów tylko obsługujące 16 bitów.
>>>
>>> Rozwiń dlaczego, proszę.
>>
>> Bo z ośmiobitowej sepii nie wycisnę tęczy.
>
> A 16-bitowej, z kiepskiego płaszczaka już dasz radę? Czy tam nawet z
> 8, konwertowanych na 16 w Szopie? Oj, coś wątpie aby to miało aż taki
> wpływ.

Najwyraźniej widać na obiektach nienaturalnych, wygenerowanych
programowo. Np pasek cieniowany od jasno niebieskiego
do ciemnoniebieskiego. W jednym wyraźne pręgi w drugim płynne
przejścia.


--
nb

do góry

de Fresz napisał:
> On 2009-03-31 13:55:39 +0200, Janko Muzykant <j...@w...pl> said:
>
>>> A na końcu i tak w obu przypadkach trzeba wynik sprowadzić do 8
>>> pozycji, więc całą dokładność diabli wezmą, bo ulegnie takiemu czy
>>> innemu zaokrągleniu.
>> Ależ skąd - gdy wielokrotnie będziemy jeździć po rzędach wielkości
>> wynik może być bardzo różny, co wynika z chwilowego przechowywania
>> argumentu z niską dokładnością.
>
> Pozostaje pytanie: jak różny? Ile to będzie, 1%? 2%? 5%?

Przy wielu skomplikowanych obliczeniach spokojnie "wyciągniesz" 5%
różnicy. Mi w podobnych okolicznościach (różnica .00 i .0000) potrafiło
dojść do 10%...

Wiesz jakie to wkurzające, że kombinujesz przez 2h jak koń pod górę
z obliczeniami i nic ci nie wychodzi a wystarczyło zmienić precyzję
i wszystko ładnie spasowało?

m.
--
- Squeak?
- SQUEAK.

do góry

On 2009-03-31 15:11:51 +0200, Mikolaj Machowski <m...@w...pl> said:

>>> Ależ skąd - gdy wielokrotnie będziemy jeździć po rzędach wielkości
>>> wynik może być bardzo różny, co wynika z chwilowego przechowywania
>>> argumentu z niską dokładnością.
>>
>> Pozostaje pytanie: jak różny? Ile to będzie, 1%? 2%? 5%?
>
> Przy wielu skomplikowanych obliczeniach spokojnie "wyciągniesz" 5%
> różnicy. Mi w podobnych okolicznościach (różnica .00 i .0000) potrafiło
> dojść do 10%...

Przy jakich skomplikowanych obliczeniach nad jakim obrazem?


> Wiesz jakie to wkurzające, że kombinujesz przez 2h jak koń pod górę
> z obliczeniami i nic ci nie wychodzi a wystarczyło zmienić precyzję
> i wszystko ładnie spasowało?

Nie wiem, bo nie wiedzieć czemu nie miewam takich problemów, mimo że
zdarza się mi w plikać dłubać, ekm, dość mocno ;-)


--
Pozdrawiam
de Fresz

do góry

de Fresz napisał:
> On 2009-03-31 15:11:51 +0200, Mikolaj Machowski <m...@w...pl> said:
>
>>>> Ależ skąd - gdy wielokrotnie będziemy jeździć po rzędach wielkości
>>>> wynik może być bardzo różny, co wynika z chwilowego przechowywania
>>>> argumentu z niską dokładnością.
>>> Pozostaje pytanie: jak różny? Ile to będzie, 1%? 2%? 5%?
>> Przy wielu skomplikowanych obliczeniach spokojnie "wyciągniesz" 5%
>> różnicy. Mi w podobnych okolicznościach (różnica .00 i .0000) potrafiło
>> dojść do 10%...
>
> Przy jakich skomplikowanych obliczeniach nad jakim obrazem?

To akurat nie były jakieś super-skomplikowane obliczenia. Algorytm do
układania x zdjęć w mozaikę o określonych wymiarach i dopóki obliczałem
z precyzją do .00 mm to ostateczny wynik musiałem w ekstremalnych
wypadkach skalować do 10%. Po zmianie skali na cztery miejsca po
przycinku wyniki były całkowicie akceptowalne.

m.
--
"Statistics are like bikinis. What they reveal is suggestive,
but what they conceal is vital" - Aaron Levenstein

do góry

On 2009-03-31 15:02:17 +0200, nb <n...@n...net> said:

>> A 16-bitowej, z kiepskiego płaszczaka już dasz radę? Czy tam nawet z
>> 8, konwertowanych na 16 w Szopie? Oj, coś wątpie aby to miało aż taki
>> wpływ.
>
> Najwyraźniej widać na obiektach nienaturalnych, wygenerowanych
> programowo. Np pasek cieniowany od jasno niebieskiego
> do ciemnoniebieskiego. W jednym wyraźne pręgi w drugim płynne
> przejścia.

Zaiste, różnica rzuca na kolana:

http://picasaweb.google.pl/deFresz/Testin#

--
Pozdrawiam
de Fresz

do góry