zdjęcia na dysku i błędy

[Marcin Debowski]

Robię właśnie większy porządek na NAS'ie gdzie trzymam bieżącą kopię m.in.
archium zdjęć. To archiwum jest trzymane na dyskach od jakiś 20 lat,
oczywiście nie wszystkie zdjęcia z tego samego okresu, ale taki z grubsza
zakres czasowy. Archiwum było od czasu do czasu przemieszczane na nowe
dyski, czy nowy NAS, słowem normalna ekspolatacja czy migracja zasobów.

No więc jest tak: z grubsza 1% zdjęć jest uszkodzonych. Manifestuje się to
w ten spob, że zdjęcie do pewnego momentu jest ok, a potem zmienia się
zwykle np. jasność i zwykle też barwa.

https://betanews.com/wp-content/uploads/2015/03/corrupt-jpeg.jpg

Wygląda mi to na błędy albo typu bit rot albo błąd np. pamięci
podczas zapisu. Pojedyńcze bity najprawdopodobniej.

A jak to wygląda u Was? Tzn, jak weźmiecie przeglądarkę do zdjęć i
przejrzycie np. 3000, ile z tego będzie tak trafionych? Dla klarowności:
to nie są błędy plików, więc plik się czyta zupełnie prawidłowo.

--
Marcin

[heby]

On 11/06/2021 10:07, Marcin Debowski wrote:
> A jak to wygląda u Was? Tzn, jak weźmiecie przeglądarkę do zdjęć i
> przejrzycie np. 3000, ile z tego będzie tak trafionych?

0% na kilka TB zdjęci i filmów.

To prawdopodobnie nie jest wina dysku, tylko metody przesyłu informacji
(siec/interfejs/OS/hardware).

NASy, bez względu na markę, to jednak dośc kiepskie softwareowo i
hardwareowo narzędzia (najczęsciej stare wersje software, albo wręcz
napisane lokalnie przez producenta własne) i możesz sie spodziewać po
nich wszystkiego, że przekłamują podczas transmisji również.

Używam NASa. Ale własnego, bazującego na normalnym OS i normalnym
hardware. Gotowe wynalazki okazały się zbyt żałosne i popsute.

[Marcin Debowski]

On 2021-06-11, heby <he...@poczta.onet.pl> wrote:
> On 11/06/2021 10:07, Marcin Debowski wrote:
>> A jak to wygląda u Was? Tzn, jak weźmiecie przeglądarkę do zdjęć i
>> przejrzycie np. 3000, ile z tego będzie tak trafionych?
>
> 0% na kilka TB zdjęci i filmów.

Kilku TB nie przejrzałeś w takim czasie. Lepiej zerknij.

> To prawdopodobnie nie jest wina dysku, tylko metody przesyłu informacji
> (siec/interfejs/OS/hardware).
>
> NASy, bez względu na markę, to jednak dośc kiepskie softwareowo i
> hardwareowo narzędzia (najczęsciej stare wersje software, albo wręcz
> napisane lokalnie przez producenta własne) i możesz sie spodziewać po
> nich wszystkiego, że przekłamują podczas transmisji również.
>
> Używam NASa. Ale własnego, bazującego na normalnym OS i normalnym
> hardware. Gotowe wynalazki okazały się zbyt żałosne i popsute.

To są moje DIY NASy. Obecny na btrfs'ie. Był co prawda Synology przez
jakieś 3 lata, ale patrz dalej. Teraz jeszcze zerknąłem na ostatnie parę
lat i jest dużo lepiej (a siedziało również na ww. Synology), więc pewnie
wszystko na poziomie 0.3%, ale jest parę zastanawiających rzeczy. Te co
dotąd sprawdziłem, to na poziomie 1% jest z Lumixa T7Z i EOSa 40D. Sony
F828, zdjęcia sprzed jakiś 18lat, może z jedno oszkodzone na tysiąc. Mały
Casio z podobnego okresu, pewnie z 2%. IxusV3, równie stare, praktycznie
zero. Chyba odkopię co mam na m-dyskach i porównam. Tylko, że na m-dyski
to poszło dopiero jakieś 5-6 lat temu. Może one byłu od początku a nie
zwróciłem uwagi? - Nb. Internety twierdzą, że najczęstszą przyczyną tego
typu wad są karty pamięci.

--
Marcin

[heby]

On 11/06/2021 12:07, Marcin Debowski wrote:
>> 0% na kilka TB zdjęci i filmów.
> Kilku TB nie przejrzałeś w takim czasie. Lepiej zerknij.

Przeglądam co miesiac od nastu lat. Automatycznie.

Nazywa się to MD5.

> Internety twierdzą, że najczęstszą przyczyną tego
> typu wad są karty pamięci.

To też prawda, na przestrzeni nastu lat wywaliłem gdzies pod ~20 kart SD
uszkadzających pojedyncze bity. Je również torturuje regularnie.

[Marcin Debowski]

On 2021-06-11, heby <he...@poczta.onet.pl> wrote:

> On 11/06/2021 12:07, Marcin Debowski wrote:
>>> 0% na kilka TB zdjęci i filmów.
>> Kilku TB nie przejrzałeś w takim czasie. Lepiej zerknij.
>
> Przeglądam co miesiac od nastu lat. Automatycznie.
>
> Nazywa się to MD5.

Dlatego przeszedłem na btrfs i dodatkowo zacząłem robić par2. Młodszym
będąc sprzętom ufałem.

--
Marcin

[Paweł Pawłowicz]

W dniu 11.06.2021 o 12:27, heby pisze:

Karty są w tej chwili na tyle tanie, że można stosować je tylko raz.
Proponuję przejrzeć te uszkodzone zdjęcia innym programem. Ciekawe, czy
będzie tak samo.

P.P.

[Marcin Debowski]

On 2021-06-11, Paweł Pawłowicz <pawel.pawlowicz13@gmailDOTcom> wrote:
> Karty są w tej chwili na tyle tanie, że można stosować je tylko raz.
> Proponuję przejrzeć te uszkodzone zdjęcia innym programem. Ciekawe, czy
> będzie tak samo.

W sumie o tym nie pomyślałem, a to dobry pomysł, choć trwałość podaje się
rzędu 10 lat. Wciąż lepsze to niż mechniczny dysk twardy, szczególnie, że
to dodatkowa kopia.

W każdym razie problem nie jest na pewno w samych aparatach bo wbudowane w
jpg miniaturki są nadal poprawne, więc w momencie zapisu na kartę tego
błędu nie było.

--
Marcin

[Paweł Pawłowicz]

W dniu 12.06.2021 o 01:14, Marcin Debowski pisze:
[...]

> W każdym razie problem nie jest na pewno w samych aparatach bo wbudowane w
> jpg miniaturki są nadal poprawne, więc w momencie zapisu na kartę tego
> błędu nie było.

Zwróć uwagę na fakt, że format jpg zmieniał się w czasie. Jeśli masz
ponad dwudziestoletnie pliki, to mogą one być niezgodne z Twoim
programem. Dlatego warto spróbować otworzyć je w paru innych programach.

P.P.

[Marcin Debowski]

Sprawdziłem, to nie to, ale jest i ciąg dalszy. Zacząłem sprawdzać stare
karty CF - EOS 40D używa jeszcze takich. Szczęśliwie wkrótce po jego
zakupie zaczęła się w kartach rewolucja i karty 1GB/2GB po wyczyszczeniu
lub nie powędrowały do pudełka. To co zostało wyczyszczone, odzyskałem
(14to letnie karty). Przejarzałem około 1000 zdjęć bezpośrednio z tych
kart i żadne nie ma takich uszkodzeń. Co więcej, znalazłem również
zdjęcia wolne od uszkodzeń, które w archiwum mają uszkodzenia. Więc to
też nie karty.

--
Marcin

[Krzysztof Halasa]

Marcin Debowski <aga...@INVALID.zoho.com> writes:

> W sumie o tym nie pomyślałem, a to dobry pomysł, choć trwałość podaje się
> rzędu 10 lat. Wciąż lepsze to niż mechniczny dysk twardy, szczególnie, że
> to dodatkowa kopia.

To raczej nie jest lepsze niż mechaniczny dysk twardy, ani nawet SSD,
aczkolwiek oczywiście każda dodatkowa kopia jest plusem.

> W każdym razie problem nie jest na pewno w samych aparatach bo wbudowane w
> jpg miniaturki są nadal poprawne, więc w momencie zapisu na kartę tego
> błędu nie było.

To nie jest prawidłowa implikacja (miniaturki mogą być poprawne mimo
uszkodzenia głównego JPEGa), ale najprawdopodobniej jednak problem leży
w NASie, transmisjach itd.

Dobrze byłoby przyjrzeć się tym uszkodzonym plikom - nie w sensie
ratowania ich, ale w sensie zbadania typu błędu. Czy to np. jest cały
zepsuty sektor (jakiej wielkości?), czy jakieś pojedyncze błędy bitowe,
bajtowe, albo jeszcze inne - często można z tego sporo wywnioskować.
Z tym że oczywiście najłatwiej znaleźć błędy przez porównanie z "dobrą"
kopią, tu to nie zadziała.

Dobrym rozwiązaniem jest przechowywanie istotnych dokumentów w kilku
kopiach, z okresowym sprawdzaniem sum kontrolnych (haszy typu MD5 albo
lepiej SHA256+ jeśli ktoś chce tam trzymać dowolne pliki - np. znane
kolizje słabszych haszy). Wtedy mamy "wczesne ostrzeganie", zwykle
wskazujące na problemy ze sprzętem.
--
Krzysztof Hałasa

[Krzysztof Halasa]

Paweł Pawłowicz <pawel.pawlowicz13@gmailDOTcom> writes:

> Zwróć uwagę na fakt, że format jpg zmieniał się w czasie. Jeśli masz
> ponad dwudziestoletnie pliki, to mogą one być niezgodne z Twoim
> programem.

Jest to nieprawdopodobne.
--
Krzysztof Hałasa

[Krzysztof Halasa]

Marcin Debowski <aga...@INVALID.zoho.com> writes:

> Co więcej, znalazłem również
> zdjęcia wolne od uszkodzeń, które w archiwum mają uszkodzenia. Więc to
> też nie karty.

O, super - łatwo więc je porównać.
--
Krzysztof Hałasa

[Marcin Debowski]

On 2021-06-12, Krzysztof Halasa <k...@pm.waw.pl> wrote:
> Marcin Debowski <aga...@INVALID.zoho.com> writes:
>
>> W sumie o tym nie pomyślałem, a to dobry pomysł, choć trwałość podaje się
>> rzędu 10 lat. Wciąż lepsze to niż mechniczny dysk twardy, szczególnie, że
>> to dodatkowa kopia.
>
> To raczej nie jest lepsze niż mechaniczny dysk twardy, ani nawet SSD,
> aczkolwiek oczywiście każda dodatkowa kopia jest plusem.

Ciekawe jak wygląda z kartami większej gęstości, bo prawdę mówiąc jestem
pozytywnie zaskoczony, że te prawie 20letnie karty są nadal bezproblemowo
czytane. Jedna tylko wywaliła błędy i/o.

> Dobrze byłoby przyjrzeć się tym uszkodzonym plikom - nie w sensie
> ratowania ich, ale w sensie zbadania typu błędu. Czy to np. jest cały
> zepsuty sektor (jakiej wielkości?), czy jakieś pojedyncze błędy bitowe,
> bajtowe, albo jeszcze inne - często można z tego sporo wywnioskować.
> Z tym że oczywiście najłatwiej znaleźć błędy przez porównanie z "dobrą"
> kopią, tu to nie zadziała.

$cmp -bl EOS40D_01772.jpg EOS40D_01772-CF.jpg
1687370 256 M-. 356 M-n

Nie mogłem ogarnąć jak to interpretować skoro to jeden bajt a tu mi jakby
wyświetla min 2, ale wziąłem edytor hex i różniaca jest A vs E, czyli
1010 vs 1110.

> Dobrym rozwiązaniem jest przechowywanie istotnych dokumentów w kilku
> kopiach, z okresowym sprawdzaniem sum kontrolnych (haszy typu MD5 albo
> lepiej SHA256+ jeśli ktoś chce tam trzymać dowolne pliki - np. znane
> kolizje słabszych haszy). Wtedy mamy "wczesne ostrzeganie", zwykle
> wskazujące na problemy ze sprzętem.

No już to mam, nawet z redundacją geograficzną, ale w kwestii tego typu
błędów mądry zacząłem być dopiero parę lat temu.

--
Marcin

[Krzysztof Halasa]

Marcin Debowski <aga...@INVALID.zoho.com> writes:

> $cmp -bl EOS40D_01772.jpg EOS40D_01772-CF.jpg
> 1687370 256 M-. 356 M-n
>
> Nie mogłem ogarnąć jak to interpretować skoro to jeden bajt a tu mi jakby
> wyświetla min 2, ale wziąłem edytor hex i różniaca jest A vs E, czyli
> 1010 vs 1110.

To jest "meta-." i "meta-n":
https://en.wikipedia.org/wiki/Meta_key

0xAE vs 0xEE, czyli różnica na 6 bicie. Tylko jeden błąd w pliku? Przy
takiej gęstości błędów pliki można odzyskać, wystarczy "wypróbować" je
po zmianie każdego potencjalnie zepsutego bitu. JPEGi składają się
z małych makrobloków (MCU - max 16x16), można nawet wzrokowo sprawdzać
efekt zmiany bitu.

Dodatkowo sprawdziłbym (np. na innych plikach, w miarę możliwości), czy
zmiana wartości jest tylko w jednym kierunku (np. 1 -> 0, nigdy
odwrotnie) - to zmniejsza liczbę potencjalnie zepsutych bitów o połowę.

Oczywiście wszystko pod warunkiem, że tych błędów nie będzie (znacznie)
więcej, albo że nie będą innego typu (np. całe skasowane sektory).

Takie pojedyncze bit-flipy wskazują na problemy z pamięcią RAM
(np. w NAS lub PC), ew. na jakieś marginalny projekt jakiejś części
urządzenia (elementy pracujące na granicy np. czasów dostępu,
częstotliwości itp). Może to być także jakiś overclocking.

Teoretycznie takie błędy mogą być wynikiem uderzeń cząstek alfa
(w pamięciach DRAM przez parzystości/ECC). Aczkolwiek nigdy takiego
przypadku nie wykryłem, mimo nie wiadomo ilu TB danych (np. skopiowanych
i sprawdzonych).
--
Krzysztof Hałasa

[Marcin Debowski]

On 2021-06-14, Krzysztof Halasa <k...@pm.waw.pl> wrote:
> Marcin Debowski <aga...@INVALID.zoho.com> writes:
>
>> $cmp -bl EOS40D_01772.jpg EOS40D_01772-CF.jpg
>> 1687370 256 M-. 356 M-n
>>
>> Nie mogłem ogarnąć jak to interpretować skoro to jeden bajt a tu mi jakby
>> wyświetla min 2, ale wziąłem edytor hex i różniaca jest A vs E, czyli
>> 1010 vs 1110.
>
> To jest "meta-." i "meta-n":
> https://en.wikipedia.org/wiki/Meta_key

Ale po co tak i co to robi pod Linuxem?

> 0xAE vs 0xEE, czyli różnica na 6 bicie. Tylko jeden błąd w pliku? Przy

Tak.

> takiej gęstości błędów pliki można odzyskać, wystarczy "wypróbować" je
> po zmianie każdego potencjalnie zepsutego bitu. JPEGi składają się
> z małych makrobloków (MCU - max 16x16), można nawet wzrokowo sprawdzać
> efekt zmiany bitu.

Tylko żeby wiedzieć gdzie jest ten bit to muszę mieć nieuszkodzony wzorzec,
a jak go mam to nie potrzebuję modyfikować.

> Dodatkowo sprawdziłbym (np. na innych plikach, w miarę możliwości), czy
> zmiana wartości jest tylko w jednym kierunku (np. 1 -> 0, nigdy
> odwrotnie) - to zmniejsza liczbę potencjalnie zepsutych bitów o połowę.

Popatrzę jeszcze.

> Takie pojedyncze bit-flipy wskazują na problemy z pamięcią RAM
> (np. w NAS lub PC), ew. na jakieś marginalny projekt jakiejś części
> urządzenia (elementy pracujące na granicy np. czasów dostępu,
> częstotliwości itp). Może to być także jakiś overclocking.

To wszystko dziwnie wygląda bo te błędy są tylko w zdjęciach z niektórych
aparatów, a w innych z tego samego okresu już nie. Zwykle archiwum
kopiowałem w całości, więc albo jakiś zbieg okoliczności, albo to jeszcze
coś innego.

> Teoretycznie takie błędy mogą być wynikiem uderzeń cząstek alfa
> (w pamięciach DRAM przez parzystości/ECC). Aczkolwiek nigdy takiego
> przypadku nie wykryłem, mimo nie wiadomo ilu TB danych (np. skopiowanych
> i sprawdzonych).

Na pewno alfa? Alfa ma bardzo słabą przenikalność.

--
Marcin

[Krzysztof Halasa]

Marcin Debowski <aga...@INVALID.zoho.com> writes:

>> To jest "meta-." i "meta-n":
>> https://en.wikipedia.org/wiki/Meta_key
>
> Ale po co tak i co to robi pod Linuxem?

Tak zostało od niepamiętnych czasów, Linuksa jeszcze nie było nawet
w planach.

>> takiej gęstości błędów pliki można odzyskać, wystarczy "wypróbować" je
>> po zmianie każdego potencjalnie zepsutego bitu. JPEGi składają się
>> z małych makrobloków (MCU - max 16x16), można nawet wzrokowo sprawdzać
>> efekt zmiany bitu.
>
> Tylko żeby wiedzieć gdzie jest ten bit to muszę mieć nieuszkodzony wzorzec,
> a jak go mam to nie potrzebuję modyfikować.

Nie, wystarczy zmieniać każdy bit (np. w uszkodzonym makrobloku)
i sprawdzać, czy się poprawiło. Przy 1 bicie/plik to jest prosta sprawa.

> To wszystko dziwnie wygląda bo te błędy są tylko w zdjęciach z niektórych
> aparatów, a w innych z tego samego okresu już nie. Zwykle archiwum
> kopiowałem w całości, więc albo jakiś zbieg okoliczności, albo to jeszcze
> coś innego.

Potrzebne śledztwo :-)

>> Teoretycznie takie błędy mogą być wynikiem uderzeń cząstek alfa
>> (w pamięciach DRAM przez parzystości/ECC). Aczkolwiek nigdy takiego
>> przypadku nie wykryłem, mimo nie wiadomo ilu TB danych (np. skopiowanych
>> i sprawdzonych).
>
> Na pewno alfa? Alfa ma bardzo słabą przenikalność.

Tak twierdzą: np. https://ieeexplore.ieee.org/document/510798
Soft errors induced by alpha particles can be a reliability concern for
microelectronics, especially semiconductor memory devices packaged in
ceramic. In dynamic random-access memory devices (DRAM), the data are
stored as the presence or absence of minority carrier charges on storage
capacitors.

Kiedyś pamięci miały parzystość (system wysypywał się z NMI po takiej
lub podobnej akcji), później było ECC (błędy były korygowane),
a jeszcze później w typowym sprzęcie usunięto wszelką nadmiarowość - od
tamtego czasu nigdy nie spotkałem się z takimi problemami. Może kwestia
"packaged in ceramic"? Ceramika też może być źródłem cząstek α.
--
Krzysztof Hałasa

[Marcin Debowski]

On 2021-06-17, Krzysztof Halasa <k...@pm.waw.pl> wrote:
> Marcin Debowski <aga...@INVALID.zoho.com> writes:
>>

>> Tylko żeby wiedzieć gdzie jest ten bit to muszę mieć nieuszkodzony wzorzec,
>> a jak go mam to nie potrzebuję modyfikować.
>
> Nie, wystarczy zmieniać każdy bit (np. w uszkodzonym makrobloku)
> i sprawdzać, czy się poprawiło. Przy 1 bicie/plik to jest prosta sprawa.

Nie rozumiem. Zmieniony jest gdzieś jeden bit a my nie znamy nawet jego
lokalizacji, to skąd wiadomo, który to makroblok? Jeśli byłoby jakieś
narzędzie pozwalające na wizualną korelacje konkretnego piksela z pozycją
w pliku, to owszem, ale są takie narzędzia?

>> To wszystko dziwnie wygląda bo te błędy są tylko w zdjęciach z niektórych
>> aparatów, a w innych z tego samego okresu już nie. Zwykle archiwum
>> kopiowałem w całości, więc albo jakiś zbieg okoliczności, albo to jeszcze
>> coś innego.
>
> Potrzebne śledztwo :-)

Nie mam dostępnych zasobów ludzkich :(

>>> Teoretycznie takie błędy mogą być wynikiem uderzeń cząstek alfa
>>> (w pamięciach DRAM przez parzystości/ECC). Aczkolwiek nigdy takiego
>>> przypadku nie wykryłem, mimo nie wiadomo ilu TB danych (np. skopiowanych
>>> i sprawdzonych).
>>
>> Na pewno alfa? Alfa ma bardzo słabą przenikalność.
>
> Tak twierdzą: np. https://ieeexplore.ieee.org/document/510798
> Soft errors induced by alpha particles can be a reliability concern for
> microelectronics, especially semiconductor memory devices packaged in
> ceramic. In dynamic random-access memory devices (DRAM), the data are
> stored as the presence or absence of minority carrier charges on storage
> capacitors.

Ciekawe.

> Kiedyś pamięci miały parzystość (system wysypywał się z NMI po takiej
> lub podobnej akcji), później było ECC (błędy były korygowane),
> a jeszcze później w typowym sprzęcie usunięto wszelką nadmiarowość - od
> tamtego czasu nigdy nie spotkałem się z takimi problemami. Może kwestia
> "packaged in ceramic"? Ceramika też może być źródłem cząstek α.

Tak, zdecydowanie.

"Alpha particles emitted from trace levels of uranium and thorium in the
packaging materials can penetrate the surface of the semiconductor die."

W takim trybie to wierzę bo tor i parę innych radioaktywnych pierwiastków
spotyka się w materiałach do produkcji ceramiki.
Ale to jest art. z AD 1996, a w tej chwili to raczej nie pakuje się takich
pamięci w ceramikę, a prędzej np. w epoksydy.

Z trzeciej strony, to się mogło uszkodzić koło 2003 :)

--
Marcin

[J.F.]

Dnia Fri, 11 Jun 2021 08:07:21 GMT, Marcin Debowski napisał(a):
> Robię właśnie większy porządek na NAS'ie gdzie trzymam bieżącą kopię m.in.
> archium zdjęć. To archiwum jest trzymane na dyskach od jakiś 20 lat,
> oczywiście nie wszystkie zdjęcia z tego samego okresu, ale taki z grubsza
> zakres czasowy. Archiwum było od czasu do czasu przemieszczane na nowe
> dyski, czy nowy NAS, słowem normalna ekspolatacja czy migracja zasobów.
>
> No więc jest tak: z grubsza 1% zdjęć jest uszkodzonych. Manifestuje się to
> w ten spob, że zdjęcie do pewnego momentu jest ok, a potem zmienia się
> zwykle np. jasność i zwykle też barwa.
>
> https://betanews.com/wp-content/uploads/2015/03/corrupt-jpeg.jpg

I zauwaz, ze przesuniecie nastapilo.

Jest to charakterystyczne dla kodowania o zmiennej dlugosci slowa,
wystepujacej w JPG - wystarczy jeden bit zmienic, aby dlugosc
odtworzonego fragmentu sie zmienila, i nastapilo takie przestawienie.

Ale widze, ze musze cos doczytac o kodowaniu JPG, bo tej zmiany koloru
i jasnosci nie bardzo rozumiem.

Tak czy inaczej - moze to byc przeklamany jeden bit, a moze byc np
wyzerowany caly sektor, bo z tego zdjecia to trudno ustalic.

Twarde dyski maja sumy kontrolne, beda probowaly wielokrotnie odczytac
sektor az moze sie kiedys uda.
Mialem kiedys uszkodzony HDD, odczyt niektorych sektorow trwal
sekundy, ale takich naprawde nieodczytywalnych bylo bardzo malo,
a bledow w tych, co sie odczytaly, to chyba nie bylo.

Ale skoro to NAS, to przyczyn moze byc wiecej - przeklamania w
transmisji sieciowej, czy np miedzy karta/chipem ethernet a pamiecia,
czy miedzy pamiecia a dyskiem. Bo zakladam, ze to juz przez procesor
nie przechodzi, ma jakies DMA.

Dobrze byloby ustalic, jakiego rodzaju sa roznice - pojedyncze bity,
czy cale sektory 512 bajtow. I czy to przypadkowe bledy przy odczycie,
czy blednie zapisane dane, ewentualnie - pozniej zmienione.

Tylko ... czy mi sie wydaje, czy ona mialaby tu dwa nosy?
Bo w gornej czesci jakby widac podstawe lewej czesci, a prawa w dolnej
czesci zdecydowanie nizej.
Cos sie zgubilo, czy wrecz odwrotnie - cos sie zduplikowalo?

J.

[J.F.]

Dnia Sun, 13 Jun 2021 01:44:45 GMT, Marcin Debowski napisał(a):
> On 2021-06-12, Krzysztof Halasa <k...@pm.waw.pl> wrote:
> $cmp -bl EOS40D_01772.jpg EOS40D_01772-CF.jpg
> 1687370 256 M-. 356 M-n
>
> Nie mogłem ogarnąć jak to interpretować skoro to jeden bajt a tu mi jakby
> wyświetla min 2, ale wziąłem edytor hex i różniaca jest A vs E, czyli
> 1010 vs 1110.

To chyba nawet tu napisane - 256/356 ... osemkowo.

J.

[J.F.]

Dnia Thu, 17 Jun 2021 16:00:21 +0200, Krzysztof Halasa napisał(a):

> Marcin Debowski <aga...@INVALID.zoho.com> writes:
>>> takiej gęstości błędów pliki można odzyskać, wystarczy "wypróbować" je
>>> po zmianie każdego potencjalnie zepsutego bitu. JPEGi składają się
>>> z małych makrobloków (MCU - max 16x16), można nawet wzrokowo sprawdzać
>>> efekt zmiany bitu.
>>
>> Tylko żeby wiedzieć gdzie jest ten bit to muszę mieć nieuszkodzony wzorzec,
>> a jak go mam to nie potrzebuję modyfikować.
>
> Nie, wystarczy zmieniać każdy bit (np. w uszkodzonym makrobloku)
> i sprawdzać, czy się poprawiło. Przy 1 bicie/plik to jest prosta sprawa.

Owszem, ale nie bardzo wiadomo, gdzie ten bit.
Bitow w zdjeciu duzo, a kontrola tylko naoczna - uciazliwe bedzie.

>> To wszystko dziwnie wygląda bo te błędy są tylko w zdjęciach z niektórych
>> aparatów, a w innych z tego samego okresu już nie. Zwykle archiwum
>> kopiowałem w całości, więc albo jakiś zbieg okoliczności, albo to jeszcze
>> coś innego.
>
> Potrzebne śledztwo :-)

A patrzyles na archiwum po skopiowaniu z aparatu?
Pewnie tak ... ale moze jednak nie ?

J.

[Krzysztof Halasa]

Marcin Debowski <aga...@INVALID.zoho.com> writes:

> Nie rozumiem. Zmieniony jest gdzieś jeden bit a my nie znamy nawet jego
> lokalizacji, to skąd wiadomo, który to makroblok?

Można próbować (raczej skryptem, nie całkiem ręcznie), np. ucinając plik
w połowie, w (odpowiedniej) 1/4 itd. Dla typowego pliku wystarczy
kilkadziesiąt prób. Pod warunkiem, że nie będzie więcej zmian bitów niż
1 w makrobloku (czy coś w tym stylu, kwestia także oceny wzrokowej).

> Jeśli byłoby jakieś
> narzędzie pozwalające na wizualną korelacje konkretnego piksela z pozycją
> w pliku, to owszem, ale są takie narzędzia?

ImageMagick pewnie wystarczy (w szczególności wyświetla ucięte pliki
JPEGi). Plus jakaś pętla z dd oraz decyzją wcześniej / później i tyle.

"Na oko" pewnie widać gdzie trzeba szukać, JPEGi pakują się pewnie dość
jednostajnie.

Ew. problemem mogłyby być pliki progresywne - ale wydaje mi się, że
aparaty raczej takich nie produkują.

Może być też tak, że zmiana będzie niewidoczna. Ale wtedy problem by nie
istniał od początku.

Gdyby ktoś miał oryginalne skróty krypto (albo nawet CRC itp.) - wtedy
wystarczy w pętli zmienić po 1 bicie, i ponownie przeliczyć skróty. Nie
jest to może superwydajne obliczeniowo (nie mamy wzrokowej oceny), ale
typowy pecet pewnie nawet kilkaset skrótów takich plików policzy w ciągu
sekundy (można też nieco zoptymalizować). Pliku z 2003 r. pewnie miały
po kilkaset KB, max kilka MB? Kilkadziesiąt minut do pojedynczych
godzin.

> Ale to jest art. z AD 1996, a w tej chwili to raczej nie pakuje się takich
> pamięci w ceramikę, a prędzej np. w epoksydy.
>
> Z trzeciej strony, to się mogło uszkodzić koło 2003 :)

To był starszy papier, ale nowsze też są. Neutrony też mogą chyba coś
powodować. Natomiast zastanawiające jest jednak to, że takich błędów nie
wykrywam. Albo są tak ekstremalnie rzadkie (typu mniej niż 1 / X TB
- to jest jednak ok. 10^-14), albo problem jest jakoś rozwiązany.

Z drugiej strony, pamiętam że jakieś większe firmy (setki+ maszyn itp.)
informowały, że jednak jakieś problemy tego typu (nie wiadomo czy
dokładnie takie) notują.


Tak na szybko napisałem krótki skrypcik w shellu, wyświetla część pliku
i pyta, czy uszkodzone miejsce jest już wyświetlone ("y") czy raczej
jest w uciętej części ("n"). Po ca 20 testach, które trwają łącznie
minutę, da się dojść do uszkodzonego miejsca. Oczywiście to tylko
przykładowy skrypcik, nie schodzi do pojedynczych bitów (tylko do
bajtu), pewnie trzeba nad nim popracować jeszcze ze dwie minuty.

I oczywiście ostrożnie z tym dd oraz of=...

#! /bin/sh

set -e

if [ $# -ne 1 ]; then
echo "Usage: $0 file_name.jpeg"
exit 1
fi

size=`stat -c %s "$1"`

echo "File $1: size $size"

bs=$(((size + 1) / 2))
start=0

while :; do
dd bs=$((1024 * 1024)) status=none count=$((start + bs)) iflag=count_bytes if="$1" of=/tmp/test.jpeg
display /tmp/test.jpeg
read -p "start $start block size $bs " visible
case "$visible" in
y)
;;
n)
start=$((start + bs))
;;
*)
continue
esac
bs=$(((bs + 1) / 2))
done

--
Krzysztof Hałasa