Marcin Debowski <a...@I...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

do góry