"Andrzej Libiszewski" 4c7658a0$0$22795$6...@n...neostrada.pl

> Tak to jest, jak się nie odróżnia podglądu zabudowanego w CR2 JPEGa od CR2

Nie musisz się chwalić tym, że nie odróżniasz. :)
Jeśli to oprogramowanie wyświetla JPG, to czym
kierujesz się modyfikując ten zapis? Intuicją?

Zmień coś w CR@ za pomocą oprogramowania Canona
i zobacz, czy uległ modyfikacji podgląd JPG.

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

"Andrzej Libiszewski" 4c765bb7$0$27023$6...@n...neostrada.pl

> Właściwie to przepraszam, w domu też go tam wrzuciłem, ale klepię z pracy.

To, co napisałeś w poprzednim swym poście tego wątku wskazuje na
to, iż nigdy nie przerabiałeś CR2 oprogramowaniem Canona -- gdybyś
przerabiał, zauważyłbyś, że zawarty tam JPG nie ulega wtedy zmianie,
podczas gdy widać wyraźnie zmiany w tym, co jest wyświetlane na
ekranie. (gdyby CR2 nie ulegał zmianie, jak można by było na
przykład zmniejszyć jasność czy kontrast lub nasycenie barw -- na czuja?)

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

On Thu, 26 Aug 2010 14:05:31 +0200, Andrzej Libiszewski wrote:
>W dniu 2010-08-26 13:30, Eneuel Leszek Ciszewski pisze:
>> Athlon z zegarkiem 500 MHz wyświetlał CR2 z aparatu C 450 D kilka razy
>> szybciej niż inne programy wyświetlały JPGi cwanie skompresowane o tej
>> samej liczbie pikseli. Byłem pod wrażeniem szybkości wyświetlania CR2
>> przez oprogramowanie Canona, gdyż znałem szybkość wyświetlania małych
>> (około 768 na 1024) JPG przez różne przeglądarki graficzne
>> skompresowanych w sposób przeciętny.
>Tak to jest, jak się nie odróżnia podglądu zabudowanego w CR2 JPEGa od CR2

A jestes pewny ze to tak ?

JPG jest dosc ambitna kompresja i wymaga troche mocy obliczeniowej.
Raw jest z kolei banalnie prosty.

Jeszcze inaczej to wyglada gdy masz sprzetowe wspomaganie, albo mocne
skalowanie, np 8:1

J.

do góry

Dnia Thu, 26 Aug 2010 17:24:50 +0200, J.F. napisał(a):

> On Thu, 26 Aug 2010 14:05:31 +0200, Andrzej Libiszewski wrote:
>>W dniu 2010-08-26 13:30, Eneuel Leszek Ciszewski pisze:
>>> Athlon z zegarkiem 500 MHz wyświetlał CR2 z aparatu C 450 D kilka razy
>>> szybciej niż inne programy wyświetlały JPGi cwanie skompresowane o tej
>>> samej liczbie pikseli. Byłem pod wrażeniem szybkości wyświetlania CR2
>>> przez oprogramowanie Canona, gdyż znałem szybkość wyświetlania małych
>>> (około 768 na 1024) JPG przez różne przeglądarki graficzne
>>> skompresowanych w sposób przeciętny.
>>Tak to jest, jak się nie odróżnia podglądu zabudowanego w CR2 JPEGa od CR2
>
> A jestes pewny ze to tak ?

Jestem. Najpierw jest pokazywany jpeg zabudowany, potem program generuje
uproszczony podgląd w rozdzielczości ekranu - na tym podglądzie toczy się
praca. Przy powiększeniu wycinka jest generowany kolejny podgląd, tego
wycinka. Finalny, pełny render, jest wykonywany przy zapisie przetworzonego
pliku na dysku.

>
> JPG jest dosc ambitna kompresja i wymaga troche mocy obliczeniowej.

Litości, dawał sobie z tym szybko radę 486...

> Raw jest z kolei banalnie prosty.

Och, jestem tego pewien.




--
Andrzej Libiszewski; JID: andrea/at/jabster.pl, GG: 5289118
"Nie zawsze wola ministrów wyznacza bieg historii i niekoniecznie
pontyfikat kapłanów porusza rękoma Boga."

do góry

"J.F." o...@4...com

> JPG jest dosc ambitna kompresja i wymaga troche mocy obliczeniowej.
> Raw jest z kolei banalnie prosty.

Dokładnie tak. :) Tyle tylko, że RAW w sobie (obok siebie?)
zawiera i inne informacje -- miniaturkę prostego JPG, rozbudowany Exif itd. :)

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

"Andrzej Libiszewski" n...@4...net

> Jestem.

To kiepsko. :)

> Najpierw jest pokazywany jpeg zabudowany, potem program generuje
> uproszczony podgląd w rozdzielczości ekranu - na tym podglądzie toczy się
> praca. Przy powiększeniu wycinka jest generowany kolejny podgląd, tego
> wycinka. Finalny, pełny render, jest wykonywany przy zapisie przetworzonego
> pliku na dysku.

Tak nie jest. (co łatwo sprawdzić choćby na przykładzie odszumiania -- zajmuje
ono czas, więc widać, czy jest dokonywane na całości obrazka czy na jego części)

I nijak się to ma do tego, że oprogramowanie Canona pokazuje
na ekranie zawartość RAWki w CR2, nie zapisanego w nim JPG.

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

"Andrzej Libiszewski" n...@4...net

> Jestem. Najpierw jest pokazywany jpeg zabudowany, potem program generuje
> uproszczony podgląd w rozdzielczości ekranu - na tym podglądzie toczy się
> praca. Przy powiększeniu wycinka jest generowany kolejny podgląd, tego
> wycinka.

W oprogramowaniu Canona tak nie jest -- może tak być, ale tak nie jest.

> Finalny, pełny render, jest wykonywany przy zapisie przetworzonego
> pliku na dysku.

Ów ,,render'' to dopisanie (modyfikacja) informacji leżącej niejako
obok mapy bitowej. Prymitywną metodą weryfikacji powyższych słów jest
obejrzenie pliku CR2 po obróbce i przed tą obróbką (zwaną przez
Ciebie dumnie renderingiem) -- można wziąć CR2, zmienić mu balans
bieli czy ekspozycję (lub cokolwiek), zapisać wynik jako A.CR2 po
czym otworzyć ów plik A.CR2 i ponownie zmodyfikować coś (na przykład
balans bieli) oraz zapisać wynik jako B.CR2 po czym porównać bajt
po bajcie A.CR2 z B.CR2 na przykład TotalCommanderem. Oba te pliki
(A.CR2 i B.CR2) będą miały tę samą długość (liczoną bajtami) i niemal
identyczną zawartość. Zmianie (w wyniku ,,renderingu'') ulegnie jedynie
informacja o wprowadzonych poprawkach. Co więcej -- można otworzyć plik
B.CR2 i ponownie zmienić balans bieli tak, iż po tym kolejnym ,,renderingu''
i zapisie ,,zrenderowanego'' pliku pod nazwą C.CR2 uzyska się plik
identyczny z plikiem A.CR2.

Każde wyświetlenie CR2 wymaga odczytania bitmapy, uwzględnienia
,,renderingu'' i przekazania do karty graficznej ,,wywołanego''
(na bieżąco renderowanego) obrazka. :)

-=-

A teraz pytanie kontrolne do tych, dla których JPG to ,,normalny
plik graficzny'' w odróżnieniu od CR2. Czy ,,normalność'' JPG
wyraża się tym, że system operacyjny po prostu wrzuca zawartość
pliki JPG do pamięci karty graficznej (karty zwykłej, przeciętnej,
najprostszej, systemowej, nie karty z hardowymi dopalaczami
specjalizującymi się w obróbce grafiki zapisanej w JPG)
bez jakiejkolwiek obróbki (bez rozkompresowania) podczas
gdy CR2 musi obrabiać CPU komputera?

Jeśli tak -- to winszuję. ;)

Aby sprawdzić, można spróbować skopiować zawartość JPG do pamięci
karty -- tak, jak się kopiuje jakiś plik na przykład z dysku na
dysk lub z dysku na ekran czy na drukarkę. :) Zwykle copy a.roz
b.roz należy uzupełnić kluczem '/b', co pozwala na unikniecie
zaprzestania kopiowania po napotkaniu znaku ,,końca pliku''. :)


Pod DOSem kopiowanie pliku na ,,ekran'' odbywać się może dzięki

copy plik.roz con/b

gdzie con jest ,,konsolą''. :) Komenda ta (pseudokomenda) pochodzi
z dawnych czasów, gdy ,,konsolą'' był terminal graficzny -- urządzenie
peryferyjne takie jak dysk, drukarka, stacja tasiemek magnetycznych czy
perforowanych lub inne urządzenie peryferyjne. :)

,,Normalny'' plik graficzny dla Windows to BMP.
Normalność ta została doceniona na przykład w budowaniu ikon systemowych,
które mogą być po prostu plikami BMP. Mogą, ale mogą też być zmodyfikowanymi
BMP -- mogę zawierać informację o palecie kolorów (na przykład można mieć
ikonę dwukolorową -- monochromatyczną tak zwaną, choć w istocie będą tam
aż dwa kolory) i mogą zawierać zbiory bitmap w różnej rozdzielczości...
(piszę o ikonach w WinDosie czy WinXP -- nie o ikonach w Win powstałych
już po ,,epoce'' WinNT)


JPG to niestety bardzo skomplikowany plik graficzny. Może być prymitywny,
ale może tez być bardzo cwanie kompresowany. Prymitywny jest łatwy w dekompresji
i kompresji, ale nie niesie gęstej informacji, zaś cwanie kompresowany może nieść
bardzo dużo informacji, bazując na niedoskonałości ludzkiego oka. :) I (co łatwo
zauważyć) JPG nie kompresuje liczby pikseli (po kompresji do JPG mamy nadal zachowaną
liczbę pikseli bitmapy) ale kompresuje kolor, podobnie jak wiele kompresorów Audio
nie kompresuje częstotliwości ramek (na przykład dając nadal częstotliwość 44.1 kHz)
ale kompresując pomija to, co rzekomo jest dla ucha obojętne, czyli przechodzenie
jakiegoś dźwięku w inny.

To nie CR2 wymaga ,,renderingu'', ale JPG. Tyle tylko, że JPG jest formatem
popularnym i uniwersalnym, podczas gdy CR2 czy inne RAWkowate są formatami
zamkniętymi i ograniczonymi do danego producenta aparatów fotograficznych
lub nawet ograniczonymi do konkretnego modelu aparatu fotograficznego.


Pomijam tu fakt, że ,,rendering'' ma się nijak do obróbki CR2. :)
Zapraszam do słowników. :)

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

Anonymouse pisze:
> 2. Na początku twojej wypowiedzi piszesz: "Nie ociepla", natomiast
> całą wypowiedź kończysz: "Zuiko ociepla". Zdecyduj się więc.

Nie Zuiko tylko każdy i nie ociepla tylko przyjmuje dominantę
przeważającej barwy kadru. Im więcej soczewek/gorsze powłoki i
oczywiście silniejszy kontrast świateł tym silniejszy efekt.
Zresztą po co ja to piszę, tylko ty i drugi pajac nie pojęliście...

--
pozdrawia Adam
różne takie tam: www.smialek.prv.pl
/przyczyną większości katastrof jest panika/

do góry