W dniu 2013-03-19 18:31, Marek Dyjor pisze:

>
> LR potrafi modyfikować rawy natywne tylko one wtedy sie nie chcą
> otwierać w programie firmowym danego aparatu.

Heeee... ciekawe :-) A jednak coś takiego istnieje :-)


>> A wiesz? Jesteś w komfortowej sytuacji teraz. Rozumiem pojęcie "grunt,
>> że działa" i dam Ci spokój. :-D
>
> ZAJMUJEMY SIE FOTOGRAFIĄ.

Chciałbym :-) Wręcz marzę o tym od początku tego wątku. Wątek był
sformułowany jak dla fotografa przerodził się w wątek jak dla
informatyka :-) Fotograf przetwarza obraz i wycofuje się z tych zmian
gdy tego potrzebuje a informatyk protestuje, że nie da się wycofać zmian
w bitmapie i protestuje, że to niewykonalne hahaha

> JPG jest formatem wygodnym i fajnym ale RAW jest lepszy bo pozwala na
> przeprowadzenie takich operacji które na pliku JPG mogłyby spowodować
> znaczną degradację wynikowego obrazu.

Mogę zaproponować inną formę w/w sentencji, która podkreśli moje
przemyślenia i praktyczne doświadczenia w pracy z różnymi formatami?
Jeśli tak, to czynię to:

"JPG jest formatem wygodnym, fajnym i LEPSZYM od RAW gdy intencją jest
zaawansowane przetwarzanie typu fotomontaż (tu szereg uzasadnień -
choćby, że RAW nie służy do tego, że RAW ma pozostać surowizną, że zapis
do RAW nie jest najlepszym pomysłem bo to i tamto itd) ale RAW jest
LEPSZY od JPG w zakresie takich operacji które na pliku JPG mogłyby
spowodować znaczną degradację wynikowego obrazu."

Błagam - bądź drugą osobą, która się ze mną zgodzi w tym zakresie :-D

--
Pozdrawiam
Marek

do góry

Dnia Tue, 19 Mar 2013 22:21:43 +0100, Marek napisał(a):

[...]
> Jako ex-informatyk nieco inaczej interpretuję definicję modyfikacji.
> Projekt w środowisku programistycznym może składać się z setek plików.
> Dokonuję zmiany w jednym z nich i całość może inaczej zadziałać. Mówi
> się wtedy, że powstała nowa wersja oprogramowania. Plik WYNIKOWY jest
> inny bo JEDNA ze składowych projektu zmieniła się. Mimo, że tylko jedna
> ze składowych zmieniła się, mówimy, że cały projekt zyskał nową wersję.

Ale nie powiesz, że zmienił się przez to ten plik, który się nie
zmienił, prawda? Zmieniło się coś innego, czyli XML, a JPG pozostał, no
chyba, że wyeksportujesz obraz po zmianach (kompilacja).

> Analogicznie tu: zmieniamy jedną ze składowych (XML), zmienia się w
> konsekwencji plik wynikowy więc CAŁY projekt (składający się ze

Zmienia się plik wynikowy, ale ty piszesz cały czas, że zmienia się ten
plik, który się akurat nie zmienia (analogia XML i obraz/bitmapa) ;).

Ja się tylko czepiam terminologii, czyli "cofania zmian w JPG", czyli
analogicznie do "cofania dokonanych zmian w skompilowanym programie".
Bzdura, prawda?

--
pozdrawiam
Sylwester Zarębski

Aby wysłać email zmień zbieracz w adresie na sylwek

do góry

Marek wrote:
>> Ważne jest czy dane są faktycznie
>> zmienione czy nie (dodanie dodatkowych warstw czy historii nie jest
>> zmianą innej).
>
> Jako ex-informatyk nieco inaczej interpretuję definicję modyfikacji.
> Projekt w środowisku programistycznym może składać się z setek plików.
> Dokonuję zmiany w jednym z nich i całość może inaczej zadziałać. Mówi
> się wtedy, że powstała nowa wersja oprogramowania. Plik WYNIKOWY jest
> inny bo JEDNA ze składowych projektu zmieniła się. Mimo, że tylko
> jedna ze składowych zmieniła się, mówimy, że cały projekt zyskał nową
> wersję.
> Analogicznie tu: zmieniamy jedną ze składowych (XML), zmienia się w
> konsekwencji plik wynikowy więc CAŁY projekt (składający się ze
> źródłowego JPG/RAW/cokolwiek + XML + wynik) zyskał "nową wersję" i
> jednocześnie łatwo jest wrócić do "starej wersji". Dlatego zapewne nie
> możemy się dogadać. Inaczej interpretujemy zagadnienie.

jezu... naprawdę przerastasz najwieksze trole internetowe...

to jest jakaś chora sofistyka...



> A więc jeśli JPG w tym środowisku "projektowym" daje mi dwie
> możliwości podejścia a RAW jedną, to 2>1 czyli JPG wygrywa 2:1. Dlatego
> napisałem o plusie bitmap nie - RAWowych.

Jezusie maryjo... z RAWa tez możesz zapisać sobei tifa czy jpga czyli
dokłądnie to samo

do góry

Marek wrote:
> W dniu 2013-03-19 20:10, Sylwester Zarębski pisze:
>> Dnia Tue, 19 Mar 2013 14:49:31 +0100, Marek napisał(a):
>>
>> [...]
>>> (nie czepiajmy się słownictwa co do pojęcia modyfikacji)
>>
>> Czepiajmy się, oj czepiajmy.
>
> hahaha - skoro chcesz ... :-)
>
>> To nie jest modyfikacja per se, tak jak można nazwać modyfikacją
>> piosenki występu karaoke (a do tego się właśnie sprowadzają zmiany
>> *obok* obrazu).
>
> Gdzieś poniżej poprosiłem Cię o zaproponowanie innego niż "historia"
> określenia przetwarzania pliku graficznego za pomocą instrukcji
> zawartych w innym pliku. Cała dyskusja bierze się z niefortunnego
> wyrażenia jakie użyłem "modyfikacja pliku JPG". Do tej pory nie wiem
> jak to ująć czytelniej. Historia zmian zaproponowana przez Ciebie jest
> równie nieadekwatna - ale skomentuj to tam gdzie poprosiłem o dalsze
> przemyślenia i propozycje :-)

edycja z zapisem historii odwracalnych zmian

do góry

Dnia Tue, 19 Mar 2013 22:44:52 +0100, Marek napisał(a):

> W dniu 2013-03-19 18:31, Marek Dyjor pisze:
[...]
>> JPG jest formatem wygodnym i fajnym ale RAW jest lepszy bo pozwala na
>> przeprowadzenie takich operacji które na pliku JPG mogłyby spowodować
>> znaczną degradację wynikowego obrazu.
[...]
> "JPG jest formatem wygodnym, fajnym i LEPSZYM od RAW gdy intencją jest
> zaawansowane przetwarzanie typu fotomontaż (tu szereg uzasadnień -
> choćby, że RAW nie służy do tego, że RAW ma pozostać surowizną, że zapis
> do RAW nie jest najlepszym pomysłem bo to i tamto itd) ale RAW jest
> LEPSZY od JPG w zakresie takich operacji które na pliku JPG mogłyby
> spowodować znaczną degradację wynikowego obrazu."

Nie, bo JPG z definicji zakłada degradację obrazu (kompresja stratna).
Gdybyś napisał, TIFF, PNG, no... to można by dywagować, ale tak?!

--
pozdrawiam
Sylwester Zarębski

Aby wysłać email zmień zbieracz w adresie na sylwek

do góry

W dniu 2013-03-19 20:34, Sylwester Zarębski pisze:
>
> Wycofywanie lub w ogóle operacje na historii działań nie wpływają na
> oryginalny obraz. To jest zapis działań, a nie obrazu, który się nie
> zmienia.
> Technicznie "cofnięcie się" jest po prostu wyświetleniem obrazu po
> ponownym przetworzeniu w pamięci aplikacji zmian "przed cofnięciem".

Tak, to wiemy od samego początku dyskusji. Chodzi teraz o kwestie
leksykalne.

>> Co gorsze: osoba czytająca to może być przeświadczona, że cofnięcie się
>> w historii zmian może być rodzajem przywrócenia stanu obrazka z
>> określonej daty a to bzdura gdyż w rzeczywistości możemy grzebać w
>> historycznym punkcie a efekty tego przeniosą się na późniejsze punkty
>> historii.
>
> To są *uproszczenia* dla "ludu",

Apelowałeś o precyzję a nie uproszczenia :-D Ja też posłużyłem się
uproszczeniem z tą modyfikacją JPG bo mylnie sądziłem, że ta grupa jest
dla fotografów a nie informatyków i co z tego wynikło? :-D :-D
Poproszę o konsekwencję i pełną wersję :-D

> Dodam, że takich narzędzi jest więcej, nie tylko dla obrazów, więc to
> żadna nowość (systemy VCS/SCM, zapis historii zmian w plikach MS Office)
> - to wszystko ma dziesiątki lat zastosowań.

A tu się nie zgodzę. Trzymanie wersji pliku jest nieadekwatne do tego o
czym rozmawiamy. Przykładowo mamy plik graficzny + XML. Zapisujemy
wersję, zmieniamy więcej niż jedną cechę np. nasycenie i kontrast,
zapisujemy nową wersję. I jak teraz powrócić do wersji z samym
nasyceniem i bez kontrastu bazując na VCS? Nie da się: trzeba otworzyć
ten tandem obraz + XML i suwakiem wyłączyć kontrast bo realna historia
operacji tam tylko występuje.

--
Pozdrawiam
Marek

do góry

Dnia Tue, 19 Mar 2013 23:16:52 +0100, Marek napisał(a):

> W dniu 2013-03-19 20:34, Sylwester Zarębski pisze:
>> Dodam, że takich narzędzi jest więcej, nie tylko dla obrazów, więc to
>> żadna nowość (systemy VCS/SCM, zapis historii zmian w plikach MS Office)
>> - to wszystko ma dziesiątki lat zastosowań.
> A tu się nie zgodzę. Trzymanie wersji pliku jest nieadekwatne do tego o
> czym rozmawiamy. Przykładowo mamy plik graficzny + XML. Zapisujemy
> wersję, zmieniamy więcej niż jedną cechę np. nasycenie i kontrast,
> zapisujemy nową wersję.

Cóż, widocznie nie wiesz/pamiętasz jak działają systemy VCS, one operują
na deltach/różnicach, czyli właśnie konkretnych zmianach/działaniach.
To jest mniej więcej odpowiednik historii w XML (opisuje ona kolejne
operacje).
Abstrahuję od różnych założeń konkretnych systemów, bo to kwestie
implementacyjne, a nie ogólnej zasady.

> I jak teraz powrócić do wersji z samym
> nasyceniem i bez kontrastu bazując na VCS?

Nie zrozumiałeś analogii. Chodziło wyłącznie o to, że taki sposób
działania jaki prezentują programy do obróbki RAW czy choćby wspomniany
przez Ciebie ACDSee mają inne programy również, a sposób jest taki, że
zapisują sobie zmiany w jednym miejscu, a pliki w drugim i wiążą dla
wygody "cofania się", itp.

> Nie da się: trzeba otworzyć
> ten tandem obraz + XML i suwakiem wyłączyć kontrast bo realna historia
> operacji tam tylko występuje.

Ale możesz sobie w XML zmienić nazwę pliku odnośnika, a nawet
najczęściej po prostu zmienić nazwę pliku XML i już zmiany magicznie
nakładają się na inny plik obrazu, a z poprzedniego magicznie znikają.

Tylko, że tu żadnej magii nie ma, bo zmiany są/były wyłącznie wirtualne.

--
pozdrawiam
Sylwester Zarębski

Aby wysłać email zmień zbieracz w adresie na sylwek

do góry

Dnia Tue, 19 Mar 2013 22:55:33 +0100, Marek Dyjor napisał(a):

>> A więc jeśli JPG w tym środowisku "projektowym" daje mi dwie
>> możliwości podejścia a RAW jedną, to 2>1 czyli JPG wygrywa 2:1. Dlatego
>> napisałem o plusie bitmap nie - RAWowych.
>
> Jezusie maryjo... z RAWa tez możesz zapisać sobei tifa czy jpga czyli
> dokłądnie to samo

No ale w samym rawie tak łatwo nie dokonasz nieodwracalnych zmian (czytaj:
nie jest łatwo go zepsuć jak obróbka okaże się zła). I to jest według Marka
wada raw w stosunku do jpg - nie dają łatwej możliwości zepsucia. A skoro
jpg ma taką możliwość, a raw nie, to jpg jest lepszy.

--
GLaF

do góry

Marek <p...@s...com> writes:

>> Jednak jest: CIDR nie służy wyłącznie do korekcji "rys",
>
> No oczywiście, że nie tylko do tego ! :-D Również można skorygować
> upstrzenia płyty CD przez muchy w ten sposób :-D

Obawiam się, że tak samo trzeba korygować także superczyste płyty.

> W CD ten narzut wynosi średnio 25% jeśli chcemy dokładnych liczb.

"Ten" tzn. samego CIDR - owszem. Z czego drugi etap CIDR, który dzięki
przeplotowi koryguje "długie" błędy odczytu, to ok. 15% danych (4 bajty
z ok. 30, nie pamiętam dokładnie ale łatwo sprawdzić). Drugie 15% - 300
bajtów w każdym 2 KB "sektorze".

Wiem, 15% i drugie 15% to nie 30%, i dokładne wartości chociaż podobne,
mogą się nieco różnić.
--
Krzysztof Halasa

do góry

Marek <p...@s...com> writes:

> Osobiście jeśli decyduję się na JPG zamiast RAW to włączam wtedy HDR i
> ustawiam ręcznie tolerancję eV. Problem dużych różnic oświetlenia w
> sporym zakresie mogę wtedy kompensować i wychodzi to zaskakująco
> dobrze. Złożenie prawdziwego HDR z kilku zdjęć w Photoshopie wychodzi
> beznadziejnie w porównaniu z tym co frimware aparatu zrobi.

Nie wiem jak w Photoshopie, ale w ogóle złożenie kilku zdjęć wychodzi
świetnie... jeśli tylko scena nam się nie zmieniła. Niestety często się
zmieniła.

Natomiast z jednego RAWa da się to zrobić (jeśli wystarczy dynamiki
oczywiście) dużo lepiej.

> Chyba nie załapałeś mojej ironii :-)

Nie wiem, ostatnio wszędzie piszą że takie te Nokie (czy coś tam)
świetne, kawę może już nawet same robią, wolę brać na poważnie.

>> Dodatkowo te JPEGi typowo robię w 50% rozdzielczości matrycy (25% liczby
>> pikseli), chyba że potrzebuję dużych powiększeń.
>
> A czemu tak? Aparat składa sąsiadujące piksele w celu poprawy dynamiki?

Nawet nie, po prostu nie potrzebuję aż tylu tych pikseli.
--
Krzysztof Halasa

do góry