Pod koniec lipca pojechaliśmy na 5 dni w okolice Locarno (Szwajcaria). Tu są ślady wycieczek rowerowych: 23, 24, 25, 26 i 27. Jak widać nie był to super wyczyn. No ale dzięki temu można było podziwiać piękne widoki w tym a zwłaszcza śliczne miasteczka z oryginalną zabudową.

Po drodze, z soboty na niedzielę, zatrzymaliśmy się w Norymberdze. W sobotę po południu zwiedzaliśmy piękną starówkę. Niedzielę rozpoczęliśmy od Germanische Nationalmuseum (wystawa poświęcona Durerowi + zbiór instrumentów muzycznych). Potem obejrzeliśmy Justizpalast. Wstęp jest płatny, w naszym przypadku było to 10,50 EUR za bilet rodzinny. Jak ktoś wie, co to były procesy norymberskie, to zwiedzanie tego miejsca można sobie darować. Nie jest to muzeum, ale coś w rodzaju izby pamięci -- eksponatów żadnych tam nie ma (co zrozumiałe). Są mniej lub bardziej znane zdjęcia. Obszerny audio przewodnik (w cenie biletu i dostępny także w języku polskim) szczegółowo opisuje przebieg wydarzeń. Słynna sala 600--miejsce procesu jest udostępniana w święta (w pozostałe dni odbywają się tam rozprawy). Ogłupione lewacką propagandą półgłówki (Głos Cadyka itp...) mogą przeżyć dysonans poznawczy widząc w tzw. środku Europy ogromnych rozmiarów krzyż wiszący nad stołem sędziowskim (mam na myśli, ich zitiere, tzw. zawłaszczenie przestrzeni publicznej przez Kościół).

Na koniec obejrzeliśmy pozostałości po tzw. 1000 letniej Rzeszy w postaci niedokończonej Kongresshalle oraz Reichsparteitagsgelände na ZeppelinFeld.

Wracając z Locarno zwiedziliśmy Pragę--pięknie miasto

Wszystkie zdjęcia z wycieczki są tutaj

Nie mogę się zalogować w programie picasa (wersja dla linuksa, 3.0 beta). Wpisując Picasa Linux signup problem do Google znalazłem podpowiedź:

cp /usr/lib/wine/wininet.dll.so  /opt/google/picasa/3.0/wine/lib/wine/ 

U mnie przynajmniej powyższe działa.

Się przy okazji okazało, że zdjęcia zawierające współrzędne geograficzne przesłane via formularz nie są traktowane jako geotagowane . Picasaweb rozpoznaje zdjęcia jako geotagowane jeżeli są ładowane programem picasa. Na flickr.com jest pod tym względem prościej, bo współrzędne geograficzne są pobierane ze zdjęcia po stronie serwera--wystarczy przesłać plik i nie jest istotne w jaki sposób...

Jak zmienić błędny czas wykonania serii zdjęć, co się może zdarzyć gdy zapomni się ustawić zegar w aparacie? Wykorzystując exiftool jest to bardzo proste. Należy umieścić wszystkie trefne pliki w pewnym katalogu a następnie wykonać polecenie:

exiftool "-DateTimeOriginal+=5:6:21 10:18:20" katalog

lub lepiej:

exiftool -AllDates-=1 katalog
exiftool -AllDates-=11:20:11 katalog

Pierwsze przesunie (w każdym pliku) datę wykonania zdjęcia (DateTimeOriginal) o 5 lat, 6 miesięcy, 21 dni, 10 godzin, 18 minut oraz 20 sekund w przód. Drugie polecenie przesuwa o godzinę do tyłu wartości trzech pól: DateTimeOriginal, CreateDate oraz ModifyDate. Trzecie przesuwa tak samo jak drugie, tylko przesuwa o 11 godzin, 20 minut oraz 11 sekund.

Manipulowanie wpisami EXIF jest dobrze opisane w dokumentacji, exiftool więc to co powyżej nie jest żadną rewelacją.

Dziś usiłowałem w ten sposób poprawić czas zdjęć zrobionych aparatem z nie ustawionym zegarem (same zera w dacie/czasie). I się nie dało, tzn.

exiftool "-DateTimeOriginal+=2010:5:11 16:00:00" katalog

Zwracał błąd (że miesiąc ma numer -1). Zadziałało za to:

exiftool "-DateTimeOriginal=2010:5:11 16:00:00" katalog

tj. bez plusa przed znakiem równości

Przy okazji: The Olympus file format is Pmddnnnn.jpg where: m is month 1-9A-C, dd is day 0--31, nnnn is number 0000-9999. The P is fixed for all Olympus Cameras. Z tego by wynikało, że moje przekonanie, że nazwy plików się nie powtarzają nie jest oparte na prawdzie.

W tym roku w tzw. długi weekend pojechaliśmy na wycieczkę (samochodem) na Litwę, a konkretnie w zamiarze zwiedzania Wilna i Troków.

Ślady GPX z wycieczki są tutaj: 20100430 | 20100501 | 20100502 | 20100503. Więcej zdjęć jest na flickr.com. Ślady w formacie KML są tutaj: 20100430 | 20100501 | 20100502 | 20100503.

Jest problem z opisami EXIF niektórych zdjęć robionych szerokokątnym obiektywem Olympus Zuiko Digital 11--22 f/2.8-3.5. Niektórymi żeby było śmieszniej -- widocznie zależy to od nastaw. Otóż jeżeli synchronizuję zdjęcia ze śladem GPS za pomocą gpsPhoto.pl, to pojawia się komunikat:

error: [minor] Bad MakerNotes directory

Komunikat generuje jakaś procedura z pakietu Image::ExifTool, wykorzystywana przez gpsPhoto.pl. Po aktualizacji exiftool do 8.06 o tyle się sytuacja zmieniła, że komunikat jest inny:

error: [minor] Bad EquipmentIFD directory.

Gdybym korzystał ze skryptu exiftool, to błąd można zignorować dodając opcję -m przy uruchamianiu skryptu. Ale ja używam gpsPhoto.pl, które z kolei korzysta z perlowego pakietu Image::ExifTool. Żeby nie modyfikować gpsPhoto.pl (beznadziejna na oko sprawa), poprawiam wpisy EXIF poniższym programem w Ruby. Słowo poprawiam oznacza dokładnie tyle, że poprawne wpisy są przepisane a błędne zignorowane. Otrzymane w rezultacie opisy EXIF są niekompletne. Opcja -m działa dokładnie identycznie.

#! /usr/bin/ruby 
# fix_tags.rb by Sijmen Mulder <sjmulder@gmail.com> in 2008. Public domain. 

files = Dir.glob("*.JPG").concat Dir.glob("*.jpg") 
 files.each do |file| 
  commands = [ 
   "cp #{file} #{file}_original", 
   "exiftool -overwrite_original -q -exif:all= \"#{file}\"", 
   "exiftool -overwrite_original -q -q -tagsfromfile \"#{file}_original\" --MakerNotes \"#{file}\" " 
 ]

puts(file) 
 commands.each do |c| 
   #puts(c) 
   system(c) 
 end 
end 

puts "Processed #{files.length} file(s)." 

Powyższy skrypt kopiuje każdy plik .jpg z bieżącego katalogu, a następnie wstawia do kopii wyłącznie poprawne wpisy EXIF z pliku oryginalnego.

Program jest w Ruby bo znaleziono go w sieci. Można by przerobić w innym języku ale mi się nie chce

Cała procedura jest taka sobie, bo poprawione pliki .jpg zawierają niekompletne opisy EXIF, ale póki co nic lepszego nie wymyśliłem.

Omyłkowo ustawiłem błędną datę w aparacie, ,,przesuniętą'' o dzień ,,do przodu''. Używając exiftool skorygowanie tego wymaga wykonania następującego polecenia:

# http://www.sno.phy.queensu.ca/~phil/exiftool/exiftool_pod.html
# przesun 24 godziny ,,do tyłu'':
exiftool -AllDates-=24:00 katalog-ze-zdjeciami

Skrypt Erika Möllera , którego używałem do ładowania zdjęć na WikiCommons przestał działać. Konsultacja na stronie wykazała, że jest outdated and should be considered deprecated and useless. Program proponowany w zamian nie podoba mi się. Może i jest dobry, ale zbytnio się różni od poprzedniego a ja nie mam czasu go rozgryzać. Znalazłem za to poprawioną wersję skryptu Möllera, która działa, tutaj (lub tutaj).

Jest ciągle problem z kodowaniem (używam domyślnie ISO-8859-2), bo po przesłaniu na WC tekst jest niepoprawnie zakodowany. Metodą prób i błędów ustaliłem, że działa dopisanie na początku skryptu czegoś takiego:

binmode( STDOUT, ':utf8' );
use open IN => ':encoding(iso-8859-2)'; ## I am using legacy encoding, ha!
use open OUT => ':utf8'; ## write utf8

Opis zdjęcia w pliku tekstowym jest w ISO, po przesłaniu na WC kodowanie jest OK. Próbowałem wysyłać pliki kodowane jako UTF-8, ale to też nie działało (mój perl jest w wersji v5.8.8).

Rysunek obok znalazłem przypadkiem. Ktoś skopiował moje zdjęcie z flickr.com na WC dodając zabawny opis...

Przy okazji ustaliłem jak przejść do ,,trybu UTF'' otwierając nowy plik w Emacs: C-x C-m f utf-8

Od pewnego czasu pobieram dane z flickr.com dotyczące najbardziej interesujących zdjęć [sposób w jaki flickr.com tworzy listę `najbardziej interesujących' zdjęć nie jest znany]. Konkretnie wykonuję flickr.interestingness.getList pobierając 500 zdjęć dla każdego kolejnego dnia.

Dla takiego zbioru policzyłem: -- średnią liczbę tagów, tagów maszynowych (tj. takich, które zawierają dwukropek, np.: geo:lat=54.00) i tagów wielowyrazowych; -- średnią liczbę zbiorów i średnią liczbę puli, do których należy zdjęcie. Wreszcie -- odsetek zdjęć geokodowanych. Wszystkie ww. statystyki w rozbiciu na kolejne miesiące...

Teza była taka, że z czasem średnie/udziały będą miały większe wartości bo użytkownicy coraz chętniej będą swoje zdjęcia oznakowywać, doceniając płynące stąd korzyści. Rosnąca liczba tagów maszynowych i/lub wielowyrazowych oraz rosnący odsetek zdjęć geokodowanych w pewnym stopniu świadczyłaby o rosnącej semantycznej precyzji metadanych na flickr.com. Dane przedstawione poniżej nie potwierdzają tego założenia:

Statystyki flickra. Od : 2006-11-28 do 2008-08-28
-----------------------------------------------------
Mc/Yr     :    Loc   MTag    Poo   RTag    Set    Tag
--> 200611:   13.9  0.067  8.810  1.704  1.543  8.975 
--> 200612:   13.3  0.064  8.690  1.740  1.501  8.942 
--> 200701:   14.0  0.066  8.607  1.603  1.596  9.281 
--> 200702:   13.8  0.063  8.862  1.413  1.654  9.675 
--> 200703:   13.4  0.063  9.159  1.398  1.679  9.936 
--> 200704:   13.6  0.056  9.556  1.434  1.703 10.302 
--> 200705:   14.4  0.056 10.229  1.432  1.700 10.568 
--> 200706:   13.2  0.057  9.968  1.386  1.688 10.217 
--> 200707:   12.8  0.048  8.136  1.401  1.613  9.547 
--> 200708:   14.0  0.059  7.770  1.585  1.773 10.249 
--> 200709:   13.5  0.053  7.321  1.638  1.767 10.174 
--> 200710:   13.6  0.057  6.939  1.610  1.743  9.722 
--> 200711:   12.9  0.055  6.698  1.532  1.714  9.392 
--> 200712:   12.4  0.048  6.698  1.606  1.749  9.644 
--> 200801:   12.1  0.052  6.818  1.599  1.685  9.456 
--> 200802:   11.2  0.049  6.962  1.603  1.664  9.401 
--> 200803:   10.4  0.049  6.786  1.637  1.675  9.457 
--> 200804:   10.3  0.049  6.475  1.623  1.672  9.315 
--> 200805:   10.6  0.053  6.505  1.661  1.690  9.205 
--> 200806:   10.0  0.047  6.369  1.693  1.650  9.023 
--> 200807:   10.0  0.038  6.534  1.664  1.658  9.101 
--> 200808:   11.1  0.048  6.181  1.726  1.715  9.471
----------------------------------------------------- 

Gdzie: Loc -- odsetek zdjęć geokodowanych; MTag -- średnia liczba tagów maszynowych; Poo -- średnia liczba puli; RTag -- średnia liczba tagów wielowyrazowych ; Set -- średnia liczba zbiorów ; Tag -- średnia liczba tagów.

Jak widać w zasadzie wartości są stałe. Można nawet zauważyć, że odsetek zdjęć geokodowanych uległ niewielkiemu obniżeniu (z 13--14, do 10--11%). Także spadła nieznacznie przeciętna liczba puli, do których wysłano zdjęcie... Liczba tagów maszynowych jest śladowa. Hmmm...

Dopisane 16 września 2008: Policzę jeszcze ww. statystyki dla danych bardziej losowych. Ściągnę mianowicie opisy zdjęć za pomocą flickr.photos.getRecent:

do { $pageno++; ## następna strona

   my $resp = get ( "http://www.flickr.com/services/rest/?" .
     "method=$method&api_key=$api_key&per_page=$max_per_page&" .
     "page=$pageno&extras=geo,views,tags,machine_tags,license" );
   ## sprawdź czy jest OK:
   eval { $photos = $parser->parse_string($resp) } ;

   unless ($@) {## pomiń stronę z błędami
     ## ... obrób dokument XML zawarty w $resp ##
   }
} while ( ($current_page < $total_pages) && ($pageno < $max_pages) );

Konstrukcja eval{ ... } służy do tego żeby skrypt się nie wywalał po fatal error tylko wykonywał następną iterację. A potrafi się wywalić na parsowaniu XML bo rzadko-bo-rzadko ale czasami coś jest nie tak z kodowaniem (UTF).

Skrypt, którego fragment jest wyżej będzie uruchamiany losowo plus/minus co 15 minut:

#!/usr/bin/perl
## Do forever with 15 min random delay or ca 4 x hour (\approx 100 per 24 hrs)
while (1) { my $runTask = `perl flickr_photo_recent.pl`;
   sleep (int(rand(600 )) + 600); }

Plan jest taki żeby ściągać dane przez 10 dni. Zakładając 100 tys zdjeć na dzień da to próbę wielkości 1 mln zdjęć.

Dopisane 26 września 2008: Niebuforowany zapis do STDOUT oraz do pliku. Sprawa ciut niejasna: w Internecie większość tekstów wskazuje, że problem załatwia nadanie zmiennej $| wartości niezerowej. Mi to jednak nie działa... W końcu znalazłem działającą odpowiedź:

#!/usr/bin/perl
use FileHandle;

# to make STDOUT flush immediately, simply set the variable $|
$| = 1;

# to prevent buffering when writing to files, set autoflush on
# the file handle
open (OUT, ">>test.out") || die "could not create test.out - $!";
OUT->autoflush(1);

print OUT "writing to file\n";

close(OUT); exit(0);

Dopisane 2 października 2008: Pierwsze wyniki dla danych z 18.09--30.09 (łącznie 364,127 zdjęć): 1) odsetek zdjęć zawierających co najmniej jeden tag: 40,77%; 2) odsetek zdjęć geotagowanych: 4,06%; 3) odsetek zdjęć tagowanych i umieszczonych w co najmniej jednym pulu: 10,17%; 4) odsetek zdjęć geotagowanych, tagowanych i umieszczonych w co najmniej jednym pulu: 1,15%. Przeciętnie zdjęcie było oznaczone 2,5 tagami. Jak widać najbardziej interesujących zdjęcia są ca 3 razy częściej geotagowane i mają 3--4 razy tyle tagów... Zrozumiałe bo znaczna część zdjęć jest wrzucana ,,jak leci'' bez oznaczenia ich czymkolwiek. Z reguły też zdjęcia takie są mało interesujące dla szerszej publiczności...

Dopisane 4 października 2008: Dziś wylosowałem 2,5% z 233520 użytkowników flickr, których zdjęcia pobrałem w ostatnich dniach. Te 2,5% to było dokładnie 5838. Ściągnąłem za pomocą flickr.people.getInfo informacje dotyczące liczby zdjęć i daty zawartej w elemencie firstdate. (The firstdate element contains the unix timestamp of the first photo uploaded by the user.). Myślałem, że to data pierwszego uploadu, ale tak nie jest. Wygląda to raczej na (opis jest raczej lakoniczny) na datę wykonania pierwszego zdjęcia zamieszczonego na flickr.com. Data ta jest zapewne odczytana z odpowiedniego pola Exif, a co za tym idzie może jej nie być, albo może być lipna... Anyway wyniki są następujące:

Wyszczególnienie    N  mediana  średnia  dominan   od.st.      max  min    Ws    Ws'
 L.zdjęć         5837   191.00   846.11   200.00  3121.26   171182    0    0.21 (0.63)
 L. dni          5837   307.00   435.80    18.00   546.00    14157    2    0.77 (0.71)

L. dni, to liczba dni od firstdate (coś w rodzaju stażu). Próba się zmniejszyła do 5837, bo z jednym użytkownikiem był problem... Ws to współczynnik skośności Pearsona (x-D)/sd (a w nawiasie podobny współczynnik skośności (Ws') liczony na podstawie Mediany, jako 3(x-Me)/sd.) Rozkłady są zatem prawostronnie asymetryczne. A ten gość co ma 170tys zdjęć jest tutaj:-). Interpretacja: 50% użytkowników, którzy publikują swoje zdjęcia ma ich mniej niż 191... BTW element count zawiera liczbę wszystkich zdjęć umieszczonych na flickr.com, nie tylko zdjęć o statusie public. Nie jest to napisane w dokumentacji ale zweryfikowałem empirycznie...

W książce Flickr Hacks Paula Bauscha i Jima Bumgardnera do manipulowania danymi w formacie XML przesyłanymi z flickr.com używa się XML::Simple. Jakoś XML::Simple nie wydaje mi się specjalnie simple w tym wypadku. Zdecydowanie wolę XML::LibXML, który pozwala przede wszystkim na dotarcie do poszczególnych fragmentów dokumentów XML w prosty sposób bez używania karkołomnych referencji. Przykładowo poniższy skrypt (fragment) wykonuje zapytanie flickr.photos.search [najistotniejszą częścią skryptu -- zaznaczoną odmiennym kolorem tła -- jest pętla do { ... }]:

use XML::LibXML;
use LWP::Simple;
use Getopt::Long;

require 'login2flickr.rc';

our $api_key;
our $my_flickr_id;

my $tags_txt;
my $show_help;
my ($user_id, $all_users, $report_views);
my @Photos;

GetOptions( "all" => \$all_users,
     "user=s" => \$user_id, "views"  => \$report_views,
     "tags=s" => \$tags_txt);

unless ( $user_id ) {  $user_id = $my_flickr_id; }
if ( $all_users ) { $user_id = ''; } ## search all photos

my $parser = XML::LibXML->new;
my $pageno;
my $method = 'flickr.photos.search';
my $max_per_page = 500;
my ($total_pages, $current_page);

my $search_query =  "&extras=geo,views"; # http://www.flickr.com/services/api/flickr.photos.search.html
if ( $user_id ) { $search_query .=  "&user_id=$user_id";  }
if ( $tags_txt ) { $search_query .=  "&tags=$tags_txt" }


do {
   $pageno++;

   my $resp = get ( "http://www.flickr.com/services/rest/?" .
       "method=$method&api_key=$api_key&per_page=$max_per_page&page=$pageno" . 
       $search_query );

   ## sprawdź czy jest OK:
   my $photos = $parser->parse_string($resp); 
   unless ( $photos->getElementsByTagName('rsp' )->[0]->getAttribute( 'stat' ) eq 'ok') { 
        die "Problems with retriving photo list!\n" }

   push @Photos, $photos->getElementsByTagName('photo' );

   $total_pages = $photos->getElementsByTagName('photos' )->[0]->getAttribute('pages' );
   $current_page = $photos->getElementsByTagName('photos' )->[0]->getAttribute('page' );

   # Dla dużych zbiorów zdjęć może długo trwać, więc wypisz że coś robisz:
   printf STDERR " *** Page %d  of %d retreived...\n", $current_page, $total_pages;

} while ( $current_page lt; $total_pages  );

## Lista @Photos zawiera wszystkie zdjęcia...
## ... dalsza część skryptu ...

Pętla jest niezbędna ponieważ flickr API organicza wielkość zwracanego dokumentu do maksymalnie 500 zdjęć. Jeżeli zdjęć jest więcej, to zapytanie należy zadać wielokrotnie, zmieniając wartość parametru page. Przy czym liczbę wszystkich stron określa wartość atrybutu pages.

Po ściągnięciu dokumentu skrypt sprawdza czy wszystko jest OK. Jeżeli tak, to za pomocą getElementsByTagName pobiera wszystkie elementy photo i dodaje je do listy @Photos. Teraz pobierane są wartości atrybutów pages/page w celu ustalenia czy wszystko już ściągnięto. Jeżeli pages < page to pętla działa dalej...

Zwracam uwagę, że od jakiegoś czasu zapytanie może zawierać parametr extras, dzięki któremu zwracany dokument XML zawiera dodatkowe informacje, takie jak: tagi, współrzędne geograficzne, liczbę odsłon, itd... Jest to opisane w API na flickr.com a także tutaj. W wyżej przedstawionym skrypcie deklaracja:

my $search_query =  "&extras=geo,views";

Oznacza, że do standardowych opisów zdjęć będą dodane także współrzędne geograficzne (oczywiście tylko wtedy gdy zdjęcia będą nimi oznaczone) oraz liczba odsłon. BTW dodanie extras=views powoduje, że kiedyś niemożliwy do wykonania poprzez API problem ustalenia ile razy zdjęcie było oglądane teraz jest jak najbardziej wykonalny. Zatem skrypty -- opisane w Nowa usługa na flickr.com oraz Czy flickr umie liczyć -- lepsze rozwiązanie -- są już niepotrzebne.

Kompletny skrypt pobierający zdjęcia z flickr.com i wypisujący plik GPX dla tych, które zawierają współrzędne geograficzne jest tutaj. Ale uwaga: próba wykonania zestawienia wszystkich wież ciśnień z flickr.com:

flickr_photo_gsearch.pl -a -t 'wieżaciśnień,wasserturm,watertower' > wasserturme-alles.xml

Skończyła się pobraniem ponad 23 tysięcy zdjęć (z tego około 6 tys. było geokodowane). Plik GPX pn. wasserturme-alles.xml miał 1,8 Mb i za nic nie szło tego wyświetlić w przeglądarce. Za duże... Mniejsze pliki są ok: kaplice [mapa ] albo moje wieże ciśnień [mapa ].

Wziąłem aparat na dzisiejsze jeżdżenie rowerowe i popstrykałem trochę zdjęć w czasie jazdy. Rowerzyści są na nich od strony rewersu widoczni w większości (por. rysunek obok), ale to tylko podnosi autentyczność--tak to wygląda w środku peletonu:-)

No i GPS złośliwie się wyłączył w okolicach Kielna czyli tak w 2/3 trasy. Akurat zdjęcia, na których kol. Rysiu mnie sfotografował nie mogą być geokodowane (aka geotagowane), bo ślad się urwał. Pech... Ale, ale... Już kiedyś tą trasą jechałem i ślad mam tyle, że nie do końca tą, pewnie z trochę inną prędokością dziś dziś ale lepsze to niż nic. Tyle, że stempel czasu dla każdego punktu na śladzie jest zły. Pomyślałem, że można by oszukać gpsphoto ,,uzupełniając'' dzisiejszy ślad kawałkiem starego. Okazało się to całkiem proste dzięki gpsbabel:

gpsbabel -t -i gpx -f plik-we.gpx -x track,move=spec-czasu -o gpx -F plik-wy.gpx

Gdzie spec-czasu ma postać znak99d99h99m99s (99 oznacza stosowną liczbę, a poszczególne składniki są opcjonalne.) Przykładowo +2h przesunie czas o dwie godziny do przodu. Podobnie +32d0h1m42s przesunie o 13 dni, minutę i 42 sekundy ,,do przodu''.

Teraz w Google maps ustaliłem gdzie się kończy dzisiejszy ślad a następnie znalazłem punkt na śladzie z 23 sierpnia z grubsza odpowiadający tej pozycji. Zrobiłem to zupełnie na piechotę metodą ,,kilku przybliżeń'' (tj. wstawiałem do pliku GPX element wpt odpowiadający punktowi ze śladu, który był ,,w okolicy'' szukanego miejsca. Oczywiście pierwszy strzał był niezbyt celny, ale po kilku podstawieniach znalazłem szukany punkt). Od tego punktu wyciąłem do końca (bo akurat do końca trasy się pokrywały) i zapisałem jako plik tmp.gpx. Teraz ustaliłem różnicę czasu między obu punktami. Do tego ostatniego zadania użyłem Perla:

#!/usr/bin/perl
# Uruchom np.: delta_days.pl -w 2008:8:24:10:2:9 -p 2008:9:6:10:3:51
use Date::Calc qw/Delta_DHMS/;
use Getopt::Long;

GetOptions("w=s" => \$wszesniej, "p=s" => \$pozniej);
@wczesniej = ex ($wszesniej); @pozniej = ex ($pozniej);

my ($d, $h, $m, $s) = Delta_DHMS(@wczesniej, @pozniej);
print "Różnica: d: $d, h: $h, m: $m, s: $s\n";

sub ex { my $w = shift ;  return ( split /[:;-]/, $w ) }

Różnica wyniosła 13 dni, minutę i 42 sekundy. Teraz uruchomiłem gpsbabela:

gpsbabel -t -i gpx -f tmp.gpx -x track,move=+13d0h1m42s -o gpx -F tmp-out.gpx

Śladem z plik tmp-out.gpx uzupełniłem dzisiejszy, niekompletny ślad. Skrypt gpsphoto (uruchomiony via My-photo-sync.sh) zsynchronizował wszystkie fotki. Oczywiście jest błąd (np. wynikający z tego, że wtedy i dziś poruszałem się z różną prędkością), ale imho jest to błąd akceptowalny...

Całość jest tutaj. No i niech ktoś się teraz nie upiera, że Windowsem i Excelem to on wszystko obliczy....:-)

Jak już jestem przy tematyce rowerowej, to szukając butów SPD dla młodego usiłowałem obejrzeć stronę WWW jednego z większych trójmiejskich sklepów. Nie udało się... nur für Windows. I to tak dramatycznie: nic nie widać, w nic nie można kliknąć...

To była ciekawa wycieczka. Zwiedzaliśmy okolice Świdnicy oraz byliśmy na Śnieżce i w Górach Stołowych (Szczeliniec/Teplice). Wracając z Teplic zwiedziliśmy klasztor w Broumovie.

Doszło do niewielkiego bałaganu w zbiorze zdjęć przywiezionych z tygodniowego pobytu w Świdnicy. Zdjęcia z kilku dni przegrałem do jednego katalogu i hop, bez zbędnego myślenia uruchomiłem skrypt gpsPhoto.pl aby dodać współrzędne geograficzne. Po tej operacji czas modyfikacji każdego pliku ze zdjęciem się zmienił no i był mały kłopot z szybkim ustaleniem w którym dniu dane zdjęcie było zrobione. Oczywiście ta informacja nie została utracona, bo jest wartością pola DateTimeOriginal, tyle że ,,z poziomu'' wiersza poleceń tego nie widać.

Już chciałem jakiś skrypt klecić żeby pobierał DateTimeOriginal a następnie zmieniał czas modyfikacji pliku, ale w dokumentacji exiftool znalazłem gotowy przykład dokładnie robiący to, co chciałem osiągnąć:

exiftool "-Directory<DateTimeOriginal" -d "%Y-%m-%d" KATALOG

Powyższe przeniesie wszystkie pliki .jpeg z katalogu KATALOG do katalogów o nazwach postaci rok-miesiąc-dzień. Daty modyfikacji pliku to nie zmienia, ale samo uporządkowanie w odpowiednich katalogach w zupełności mi wystarczy.

Mój GPS Logger (używam Iblue 747) dwa razy zarejestrował ślad zawierający kolosalne odchylenie (biegun północny, tj. lat="90.000000000" lon="0.000000000"). Wcześniej nie obserwowałem tego fenomenu, tj. mówiąc dokładnie Etrex H nagminnie oszukuje podając np. średnią/maksymalną prędkość, ale zwykle zgrany ślad jest OK. Próbowałem poszukać jakiś automatycznych sposobów usunięcia takich anomalii ale nie znalazłem. Ostatecznie problem jest źle zdefiniowany więc automatem się nie da. Potrzebny jest edytor i wizualna inspekcja (np. MapSource ale to wyłącznie windziana aplikacja). Z braku takowego ślad wyświetlam na Google Maps a rażące odchylenia usuwam patrząc na współrzędne. Na moje potrzeby super korekta śladu nie jest potrzebna. Tak nawiasem mówiąc wspólnym mianownikiem Loggera i Etrexa jest chip firmy MTK. Ciekawe czy wszystkie czułe GPSy typu Sirf3/MTK robią takie błędy czy tylko MTK?

Ślady w formacie KML ze zdjęciami umieściłem tutaj: świdnica--książ | wlk.sowa--ludwikowice | szczeliniec--wambierzyce | karpacz--śnieżka | kompleks--osówka+zamek grodno | teplice--broumov | ślęża--tąpadła--sulistrowiczki

Pakiet Net::Flickr::Backup, o którym pisałem niedawno nie działa prawidłowo. Dziś ustaliłem co jest nie tak i szczegółowo opisałem w tamtym wpisie.

Stocznia złomowa (ship-breaking yard): ,,zakład zajmujący się rozbiórką i cięciem na złom jednostek pływających. W latach 70. i 80. w Polsce złomowanie odbywało się w porcie wojennym w Gdyni.'' Obecnie większość stoczni złomowych znajduje się w krajach takich jak Indie (Alang), Bangladesz (Chittagong), Pakistan (Gadani) i Chiny.

Praca zatrudnionych tam ludzi wygląda z grubsza tak jak niewolników przy budowie piramid w Egipcie. Wpisując Alang | Chittagong | Gadani + ship-breaking można znaleźć wiele materiałów -- w tym zdjęć -- na ten temat. Jest też trochę zdjęć na flickr.com. Natomiast na googleearth prawie nic nie ma -- jeżeli chodzi o fotografie, za to można obejrzeć jak to wszystko wygląda z lotu ptaka (pierwszy z poniżej zamieszczonych zrzutów z GE przedstawia Alang (lat=21.3847285601, lon=72.1748265443) -- wyróżnia się wrak ex brazylijskiego lekkiego lotniskowca Minas Gerais):

Znalazłem informację -- czytając pl.rec.foto.cyfrowa -- na temat innego programu do synchronizacji śladu ze zdjęciami, pn. gpicsync. Nie próbowałem ale jest chwalony. No i jest dostępny nie tylko w wersji nür für Windows.

Od dłuższego już czasu przymierzałem się do zrobienia katalogu moich zdjęć umieszczonych na flickr.com. Ponieważ przed wysłaniem zdjęcia na flickr.com jego opis w postaci tagów i współrzędnych kopiuję do pliku ze zdjęciem (do odpowiednich pól EXIF) więc teoretycznie ów katalog można by zbudować wydłubując teraz to co trzeba z każdego pliku z osobna. Można by ale... Ale nie zawsze opis na flickr.com zgadza się z opisem lokalnym, bo jak coś spapram to już drugi raz nie ładuję tylko poprawiam ręcznie, bo kiedyś skrypt umieszczający zdjęcia działał inaczej, itd... Mówiąc krótko prościej będzie ściągnąć to wszystko z powrotem z flickr.com. Zrobiłem rozpoznanie w google i się okazało, że jest narzędzie pn. Net::Flickr::Backup służące dokładnie do tego co chcę zrobić: ściągnąć każde zdjęcie z konta na flickr.com wraz z opisem, który to opis zostanie zapisany w formacie RDF. Co dalej będzie z tym RDF-em -- zobaczymy jak się ściągnie.

Postępując zgodnie ze wskazówkami ze strony leobard.twoday.net zainstalowałem moduł Net::Flickr::Backup:

perl -MCPAN -e 'install Net::Flickr::Backup'
yum install perl-XML-LibXML perl-XML-LibXML-Common

Polecenie yum instaluje moduł XML::LibXML, niezbędny do działania Net::Flickr::Backup. W przypadku fedory moduł ten znajduje się w pakiecie perl-XML-LibXML. (Uwaga: zgodnie z tym co napisano na ww. stronie dla systemów Debianowych odpowiednikiem perl-XML-LibXML jest pakiet libxml-libxml-perl.) Na wszelki wypadek doinstalowałem też perl-XML-LibXML-Common, być może niepotrzebnie. Teraz przepisałem zawartość pliku backup-flickr.pl ze wspomnianej wyżej strony (a na tej stronie z kolei jest to przepisane z dokumentacji:-):

#!/usr/bin/perl
#
use Net::Flickr::Backup;
use Log::Dispatch::Screen;
use Config::Simple;

my $CFGFILE = "$ENV{HOME}/.flickr/flickr_backuprc";
my $cfg = new Config::Simple(filename=>"$CFGFILE");

my $flickr = Net::Flickr::Backup->new($cfg);
my $feedback = Log::Dispatch::Screen->new('name' => 'info', 'min_level' => 'info');

$flickr->log()->add($feedback);
$flickr->backup(); 

oraz utworzyłem w katalogu ~/.flickr/ plik konfiguracyjny flickr_backuprc o następującej zawartości:

#
# http://leobard.twoday.net/stories/4122767/
# ###
[flickr]
api_key=AAAAAAAAAAAAAAAAAAAA
api_secret=BBBBBBBBBBBBBBBBBB
auth_token=CCCCCCCCCCCCCC
api_handler=LibXML

[backup]
photos_root=/cmn/archive/Flickr/backup
scrub_backups=1
fetch_original=0
fetch_medium=0
fetch_square=1
force=0

[rdf]
do_dump=1
#rdfdump_root=/home/asc/photos

Uruchomienie perl backup-flickr.pl skończyło się wkrótce błędem dotyczącym kodowania:

Can't escape \x{0119}, try uri_escape_utf8() instead at \
   /usr/local/share/perl/5.8.8/Net/Flickr/RDF.pm line 1497

Z opisu wynika, że coś jest nie tak w pliku RDF.pm. Przy bliższej inspekcji okazało się, że nazwy miejscowości, zawierające polskie znaki (np. Rębiechowo) nie mogą być zakodowane poprawnie przez procedurę uri_escape (Nazwy geograficzne są używane do tworzenia URI postaci: http://www.flickr.com/places/Poland/Pomorskie/Rębiechowo.)

Nie do końca jestem pewien czy dobrze robię ale wymieniłem (dwukrotnie) wywołanie procedury uri_escape na:

URI::Escape::uri_escape_utf8

Teraz program działa. Zostawiłem go na noc żeby zrobić kopię ale się okazało, że kopiowanie działa bardzo wolno. Przez noc ściągnęło się niewiele; potem jak wyłączyłem maszynę ponownie, to wprawdzie program nie ściągał danych drugi raz, ale samo sprawdzanie, w którym miejscu skończył zajęło mu okropnie dużo czasu. Ponieważ mam dostęp -- od jakiegoś czasu -- do tajnego serwera w pracy więc postanowiłem zrobić kopię wykorzystując ową maszynę.

Maszyna jest całkowicie out-of-date i dodatkowo zainstalowałem na niej Ubuntu... Zainstalowałem zaś Ubuntu z tej prozaicznej przyczyny, że nie mogłem znaleźć dysków z instalacją Fedory a jakąś instalkę Ubuntu akurat miałem pod ręką. Jak powszechnie wiadomo Ubuntu i Fedora różnią się nieco, w szczególności różnią się program służącym do instalowania i aktualizacji systemu.

Próba zainstalowania Net::Flickr::Backup tak jak w Fedorze, tj. poprzez perl -MCPAN -e '...' skończyła się błędem na etapie instalowania pakietu SOAP-Lite. Rozczarowujące, ale się nie załamałem:-) Zrobiłem upgrade a potem zainstalowałem dla pewności SOAP-Lite aptem (akurat był dostępny):

apt-get upgrade # 
aptitude search SOAP-Lite # jaki pakiet zawiera SOAP-Lite ?
apt-get install libsoap-lite-perl # instaluję SOAP-Lite

Teraz polecenie

perl -MCPAN -e 'install Net::Flickr::Backup'

Zostało wykonanie pomyślnie. Poprawiam teraz uri_escape na uri_escape_utf8 w sposób opisany wyżej. Kopiuję do ~/.flickr/ plik flickr_backuprc także opisany wyżej.

Teraz mogę uruchomić:

 ./backup-flickr.pl > BACKUP_FLICKR.LOG  2>&1 &

Wygląda, że działa. I mogę się wylogować. Zobaczymy za parę dni czym to się wszystko skończy.

Dla przypomnienia, zapis >BACKUP_FLICKR.LOG 2>&1 wysyła strumienie stdout i stderr do pliku BACKUP_FLICKR.LOG.

Dopisane 4 sierpnia 2008: Bardziej fundamentalny problem się pojawił. Mianowicie, identyfikatory zdjęć (photo_id), które m.in. definiują adres URL do strony ze zdjęciem są całkowicie do kitu, np.:

<flickr:photo rdf:about="http://www.flickr.com/photos/20425995@N00/-1617918774">

Trudno nawet powiedzieć do jakiego zdjęcia odnosi się powyższe. Przy bliższym oglądzie stwierdziłem co następuje: photo_id są ok dla zdjęć wysłanych na flickr przed rokiem 2008. Zacząłem podejrzewać że gdzieś się ,,licznik przekręcił'', ale jak to się stało w językach beztypowych takich jak Perl? Ponieważ nie za bardzo mi się chciało dłubać w kodzie Net::Flickr::Backup zgłosiłem błąd korzystając -- zgodnie z tym co jest napisane w dokumentacji pakietu -- z http://rt.cpan.org. Do samego zgłoszenia błędu wystarczy napisać list na adres bug-Net-Flickr-Backup@rt.cpan.org (do komentowania trzeba się zarejestrować). Mój raport jest tutaj.

Wygląda, że nikt tego Net::Flickr::Backup nie używa, bo przez 12 dni pies z kulawą nogą się nie odezwał. Ponieważ sprawa nie dawała mi spokoju zacząłem dziś drążyć temat. W szczególności przyjrzałem się jak działa procedura backup zdefiniowana w Net/Flickr/Backup.pm. Podejrzenie padło na wiersz:

 $self->log()->info(sprintf("process image %d (%s)",
       $id, &_clean($node->getAttribute("title"))));

A konkretnie specyfikację %d funkcji sprintf. Hmm..., jaka jest maksymalna/minimalna wartość dla liczby całkowitej w Perlu? Doczytałem, że jest to system-dependent i można ją ustalić wykonując poniższy skrypt (znalezione na stronie www.issociate.de):

perl -le 'use POSIX; print for SHRT_MAX, INT_MAX, LONG_MAX, FLT_MAX, DBL_MAX;'

U mnie INT_MAX wynosi 2147483647 (tyle samo wynosi LONG_MAX btw) a przykładowo id tego zdjęcia to 2727375455. Ewidentnie 2727375455 jest większe od 2147483647, więc Net::Flickr::Backup nie może działać prawidłowo. Pozostało teraz ustalić jak jest definiowane photo_id w dokumentacji API flickr.com. Jakoś trudno znaleźć, ale jest po dłuższym szukaniu udało się ustalić co następuje: (por. tutaj): The Flickr API exposes identifiers for users, photos, photosets and other uniquely identifiable objects. These IDs should always be treated as opaque strings, rather than integers of any specific type. The format of the IDs can change over time, so relying on the current format may cause you problems in the future. .

Wymieniłem %d na %s w Net/Flickr/Backup.pm oraz Net/Flickr/RDF.pm, wszędzie tam gdzie jest drukowane photo_id. Mam nadzieję, że nie pominąłem niczego i teraz da się zrobić poprawnie backup flikra.

Kupiłem do E-510 lepsze obiektywy, konkretnie używane na ebay.com. Na allegro mało jest ofert sprzedaży obiektywów Olympusa. Są wprawdzie w ciągłej sprzedaży z przemytu z USA, ale w ten biznes nie chciałem wchodzić. Nowy Zuiko 14-54 ED kosztuje wg. ceneo minimum 1700 zł, z przemytu via Allegro ca 1300--1400 zł. Ja kupiłem za 950 zł na ebay.co.uk. Jeszcze taniej jest na ebay.com ale później kłopot pn. urząd celny. Założyłem, że nie ma sensu aż tak bardzo oszczędzać:-) Do tego 14-54 dokupiłem jeszcze drugi, większy 50-200 ED. To jest starszy model, bez napędu SWD.

Nowe obiektywy są dużo jaśniejsze niż te standardowe, dołączane ,,w promocji'' do aparatu. Są też znacząco cięższe. Różnicę widać patrząc na średnicę soczewek (cf. zdjęcie obok).

Uparcie nie mogłem go znaleźć, ale w końcu jest i to 30 metrów od mojego bloku na skwerze posypanym zeszłej jesieni korą. Widocznie ta kora była z grzybnią...

Znalezisko uwidoczniłem na zdjęciach, np: [1] [2]. Wg. mnie smardz stożkowaty alias morchella conica. Uwaga: smardz jest pod ścisłą ochroną w Polsce. Niestety jakiś troglodyta o tym nie wiedział i już następnego dnia smardzy nie było.

Königsstuhl

W tzw. długi weekend pojechaliśmy na wycieczkę (samochodem) do północnych Niemiec: Kilonia, Lubeka, wyspa Rugia. Pod Kilonią w miejscowości Laboe jest Das Technische Museum, pod którą to nazwą kryje się U-Boot udostępniony do zwiedzania. Jest to okręt typu VIIC o numerze 995, czyli trzeba wpisać U-995 do Google jakby ktoś chciał poszukać w Internecie więcej informacji na ten temat. Obok jest coś w rodzaju mauzoleum (Marine-Ehrenmal) i wieża. Nic ciekawego--jakaś ekspozycja nt. Bundesmarine + modele okrętów + coś tam jeszcze. Opisy wyłącznie po niemiecku... Można sobie śmiało darować. Z wieży oczywiście lepiej widać okolicę, więc jak ktoś jest ciekaw to może sobie wjechać windą.

Obok Laboe, bliżej Kilonii, w miejscowości Möltenort jest jeszcze jedno mauzoleum. Upamiętnia ono załogi okrętów podwodnych Kriegsmarine (U-boot Ehrenmal). Dla niezorientowanych: 80% U-Bootów, tj. około 840 z 1100, które weszły do służby zostało zatopionych. Wiele łodzi zostało zniszczonych w pierwszym rejsie, często pierwszy kontakt z wrogiem był dla załogi kontaktem śmiertelnym i ostatnim. Z tego co pamiętam około 40% łodzi nie zatopiło żadnego statku. Zginęło ok. 28000 spośród ok. 40000 marynarzy. Do tego cała sprawa była z góry przegrana (wojny o Atlantyk Ubootwaffe nie mogła wygrać), a poświęcenie tych ludzi z góry skazane na niepowodzenie i bezsensowne.

Zwiedzanie U-boota było w czwartek, w piątek pojechaliśmy do Lubeki i cały dzień zwiedzaliśmy stare miasto, szczególnie zwracając uwagę na kościół St Marien Kirche w którym Orgelmeisterem był Dietrich Buxtehude, (cf. Buxtehude -- zapomniany geniusz z Lubeki). BTW organów mistrza już nie ma bo się spaliły w 1942 roku w czasie nalotu RAF.

Wreszcie w sobotę jeździliśmy po Rugii. Byliśmy w Narodowym Parku Jasmund i oglądaliśmy Königsstuhl. Okazało się, że w Sassnitz stoi przycumowany jeszcze jeden okręt podwodny: HMS Otus. Dużo większy od U-995, bo to powojenna konstrukcja--nie zwiedzaliśmy. Potem zamek myśliwski Jagdschloss Granitz i powrót do domu z noclegiem u znajomych w Świnoujściu.

Zrobiłem dużo zdjęć ale wyszły tak sobie. Specjalnie na U-boota kupiłem lampę (FL-36, używaną na Allego), którą zresztą mało nie rozbiłem przez nieuwagę. Ostatecznie straciłem tam tylko jeden akumulator AA, który wtoczył się pod pokrywy podłogi i przepadł w czeluściach okrętu.

Ślad GPX z wycieczki jest tutaj. Więcej zdjęć jest na flickr.com. Ślad w formacie KML w przygotowaniu...

Dopisane 8 maja 2008: Przebytą trasę rejestrowałem moim bt747 (aka Iblue 747); teoretycznie logger powinien zmieścić zapis 20 godzinny ale dla pewności zgrywałem ślad codziennie. Po przyjeździe zagregowałem całość używając gpsbabela:

#!/bin/bash
gpsbabel -t -i gpx -f 20080501.gpx -i gpx -f 20080502.gpx \
   -i gpx -f 20080503.gpx -i gpx -f 20080504.gpx \
   -x track,merge,title="Trip to Laboe 30/4--4/5 2008" \
   -x simplify,count=2000 -o gpx -F sopot-laboe-sopot.gpx && \
grep -v '<course>0.000000</course>\|<fix>2d</fix>\|<ele>0.000000</ele>' \
   sopot-laboe-sopot.gpx > sopot-laboe-sopot_s.gpx

Teraz używając opisanych na innych stronach tego bloga skryptu gpsPhoto.pl dodałem współrzędne geograficzne do zdjęć. Kilkanaście zdjęć nie zostało oznakowanych -- wszystkie nieoznakowane były robione wewnątrz U-boota. Nic dziwnego zresztą bo toto ma podwójny stalowy kadłub w tym wewnętrzny dość gruby. Nie pamiętam ile konkretnie milimetrów, ale U-booty potrafiły się zanurzać na ponad 250 metrów, szacun!

Oczywistym rozwiązaniem jest dodanie współrzędnych ze zdjęć zrobionych w tym samym miejscu w momencie gdy GPS logger ,,widział'' niebo. Używając exiftool jest to banalnie proste:

#!/bin/bash
exiftool -TagsFromFile plik-bez-wsp -GPSLatitude -GPSLongitude -GPSLatitudeRef -GPSLongitudeRef plik-z-wsp

Dodałem też możliwość uruchomienia ww. skryptu moim w trybie Emacsa służącym do ładowania zdjęć na flickr.com. Działa to w ten sposób, że kopiowane są współrzędne GPS z pliku podanego w wierszu minibufora do pliku, którego nazwa znajduje się w wierszu bieżącym (tj. wierszu, w którym jest kursor).

Na ,,odcinku'' ładowania zdjęć też się popsuło. Mój skrypt przestał obracać zdjęcia zrobione w układzie portretowym. Przestała działać metoda flickr.photos.transform.rotate i to w dość dziwny sposób: zwracany komunikat jest OK, ale obrazek nie jest obracany. Do tego wykonanie flickr.photos.transform.rotate oddzielnym skryptem działa. Podejrzewam braci Flickr, że coś zmienili na serwerze i namieszali. Ostatecznie zmieniłem strategię: zdjęcia są obracane ,,fizycznie'', z użyciem jpegtran wywołanym z ,,wnętrza'' skryptu perlowego za pomocą system().

Po załadowaniu zdjęć na flickr.com. Poprawiłem plik KML używając do tego skryptów kml-adjust-urls/kml-skip-deadlinks.

Plik są tutaj: KML oraz GPX.

Próba załadowania zdjęcia -- w formacie jpeg -- o wielkości 2344484 bajtów kończy się komunikatem the size of the photo should be less than 5MB. Jest jakieś niekonkluzywne zamieszanie ,,w temacie'' na listach dotyczących Panoramio. Podejrzewam błąd po stronie serwera i/lub, że P. liczy wielkość pliku po rozpakowaniu (aczkolwiek nigdzie o tym nie jest napisane). Anyway, po nieznacznym zmniejszeniu:

convert p4260616.jpg -quality 80 p4260616_s.jpg

Plik ma teraz 2013114 bajtów i jest już OK. Swoją drogą komunikat mógłby być uzupełniony o informację jaka jest wielkość ładowanego pliku wg. Panoramio.

Przełączyłem aparat na format RAW a do zamiany plików w tym formacie (rozszerzenie .orf) na tiff użyłem dcraw, np.:

dcraw -T plik.orf # zamiana poj. pliku
for i in *.orf; do dcraw -T $i ; done

Pliki są nieskompresowane, więc następnie:

convert plik.tiff -compress ZIP plik_z.tiff # albo
mogrify -compress ZIP plik.tiff

Program mogrify modyfikuje plik oryginalny

Zamiana tiffa na jpeg z wykorzystaniem convert wygląda zaś następująco:

for i in *.tiff; do convert $i `basename $i .tiff`.jpg ; done

Powyższe ma jeden dyskwalifikujący brak: dcraw usuwa dane EXIF. Szukając rozwiązania znalazłem dwa skrypty basha do konwersji z zachowaniem metadanych: Converting RAW images to JPEG with Exif on Fedora oraz wrapper script for dcraw. Pierwszy ze skryptów używa exiv2 a ja mam awersję do tego programu (być może niesłuszną, ale kiedyś mi podpadł). Drugi niby jest dla Nikona, ale żeby działał z Olympusem to wystarczy zmienić nef na orf w jednym wierszu (oprócz tego uprościłem skrypt, bo był sophisticated zbytnio i niepotrzebnie):

#!/bin/bash
# http://www.howtofixcomputers.com/forums/digital-photo/my-humble-contribution-wrapper-script-dcraw-linux-4360.html
# Zamiana plików ORF (Olympus) na JPEG z zachowaniem danych EXIF
# Wykorzystuje dcraw, cjpeg (do kompresji) oraz exiftool
#
DCRAW="dcraw -w -c "

while [ $# -ge 1 ]
do

JPEG=`basename $1 .orf`.jpg
echo "Converting $1 => ${JPEG}..."
$DCRAW $1 | cjpeg -quality 90 > $JPEG || echo " *** Problem writing "

# transfer EXIF data from the original raw file
exiftool -overwrite_original -TagsFromFile "$1" "$JPEG" >/dev/null

shift
done

Przy okazji znalazłem link do konferencji Libre Graphics Meeting.

Dopisane 27 kwietnia 2008: zmieniłem ustawienia w aparacie na zapis RAW+HQ. Poprzednio było RAW, a przedtem HQ. HQ zapisuje prawie że identyczne ,,objętościowo'' pliki .jpg o wielkości 2Mb (z ogonkiem). Nie ustaliłem jeszcze czemu ale pliki konwertowane z RAW różnią się znacząco wielkością (ten sam parametr quality oczywiście) a te produkowane przez aparat są takie same.

Obrazek, bo to nie jest zdjęcie, tylko zrzut ekranu. Dziś liczba odsłon doszła do 1000. Wielki sukces:-) Nie znam przyczyn tego fenomenu, ale zrzuty z ekranu wydają się cieszyć dużo wielką popularnością niż zdjęcia. Panie z reklam bielizny nie mają najmniejszych szans nawiązać z Emacsem -- najpopularniejsza była oglądana zaledwie 135 razy. A zdjęcie oznaczone prowokacyjnie jako big cock to już się zupełną klapą okazało (5 razy oglądane).