Plan działania czyli jak to sobie wyobrażamy

[Jacek M. S.]

istnieją narzędzia na licencji GPL pozwalające na tworzenie dokumentów DjVu i korzystanie z dobrodziejstw tego formatu.

A moglbys podac nazwy tych narzędzi i ew. linki do stron.

[nazgulos]

A moglbys podac nazwy tych narzędzi i ew. linki do stron.

To może wyręczę: http://djvu.org/links/
Najbardziej interesującym projektem wydaje się DjVuLibre.

[Rafał Rufus Magryś]

Witam,

 Djvu to fajny format ale wolna implemetacja (wg moich testów) jest wolna. Zastrzegam, że testowałem wcześniejsze wersje. (Pliki wyjściowe jpegi rozmiar 3-4mb, czas produkcji djvu ok. 5 minut na plik).

Pozdrawiam,

[mikmach]

Djvu jest mocno stratnym formatem. Wg mnie najlepsze byłoby archiwum dwupoziomowe:

1) wysokiej jakości zdjęcia/skany w PNG/TIFF, plik na stronę opisany metadanymi; obraz poddany minimalnej obróbce graficznej, z miarką, kolorystycznym paskiem kalibracyjnym.
2) opracowane w pewnym stopniu dokumenty PDF/DjVu, wielostronicowe w jednym pliku, itd.

W ten sposób badacze potrzebujący wielu informacji o warstwie zewnętrznej źródła mobliby wykorzystać warstwę pierwszą, wszystkim innym możnaby udostępnić warstwę drugą jednocześnie oszczędzając pasmo.

[minder]

W przypadku posiadania odpowiedniej ilości mocy przerobowej (hmmm... BOINC, microwulf?), żadna konwersja nie jest straszna DjVu jest kilkukrotnie szybszy w odczycie niż PDF czy nawet JPEG. No i fakt, że został specjalnie zaprojektowany dla celów archiwalnych chyba jednak coś znaczy?

Pomysł z dwupoziomowym archiwum nie jest zły.

Co do samego procesu digitalizacji, to popieram opinię, żeby brać przykład z OpenLibrary i Internet Archive.

Jeśli natomiast chodzi o późniejsze udostępnianie - proponuję torrent, żeby możliwie odciążyć serwery. W ten sposób w najgorszym razie użytkownik będzie pobierał bezpośrednio z Archiwum, jeśli nikt inny nie będzie miał danego pliku u siebie. W ten sposób można też łatwo rozdzielić transfer na kilka serwerów umieszczonych w kraju. Opera już ma klient torrentów, Firefox ma wtyczkę. Niedługo torrent będzie standardem pobierania plików z sieci, bo ściąganie indywidualne jest po prostu nieekonomiczne. To jednak w odleglejszej przyszłości.

Poza tym trzymam kciuki i deklaruję pomoc w miarę możliwości oraz promocję wśród młodzieży stale.

[firestarter]

Jeśli wybierzecie bit torrent musicie zdawać sobie sprawę z kilku rzeczy:
*im więcej osób ściąga i wysyła daną rzecz tym mniejsze wykorzystanie serwera głównego (+)
*kwestia mirrorowania - jeśli by istniało kilka serwerów na których by były te pliki udostępniane można te same dane ściągać z kilku serwerów naraz. Pada jeden nic wielkiego z udostępnianiem plików się nie dzieje, ludzie nadal mogą to ściągać (+)
*jeśli będziecie popularni mogą ze względu na używanie bit torrenta wykorzystać w wojnie pomiędzy piratami i organizacjami takimi jak ZAiKS (-)
*duża ilość plików hostowana przy użyciu bit torrenta skutecznie zabija serwer (-)

Bit torrent idealnie nadaje się do rozprowadzania dużych plików lub dużej ilości kopi naraz - serwery wysyłają dane pomiędzy sobą - ale rozprowadanie małych plików to zabijanie serwera.

Kolejna ważna kwestia:
Jakie rzeczy chcecie archiwizować ?
Należy jasno i precyzyjnie określić jakie pliki mogą być archiwizowane, a jakie nie. Bo jak ludzie będą archiwizować dobra kulturalne polskiej kinematografii i muzyki, to zostanie warezem z polskimi filmami i muzyką, przy okazji wymiatając mniejsze strony tego typu. Lekkie rozeznanie w tej materii mam i jeśli będą tutaj filmy to przyciągniecie rzesze piratów.

A teraz istotna rzecz:
Miejsce. Takie archiwa potrzebują znaczne ilości miejsca na dysku. Jaki macie pomysł na to? - Ten problem będzie wracał jak bumerang.

[Rafał Rufus Magryś]

Witam,

 Pozwolę sobie na odniesienie się do uwag jakie się tu pojawiły. Po pierwsze jak zauważyliście powoli zaczynają się pojawiać informacje na temat tego co jest potrzebne w tym momencie dla NAC w dziale bezpośrednio dotyczącym tego zagadnienia.
Już niedługo (gdzieś koło soboty) pojawią się informacje dokładnie jak wydzimy zasadę działania NAC (w aspekcie technicznym).
Co do samego procesu digitalizacji to akurat on nie jest problemem mamy kadry (oczywiście za mało) i specjalistów którzy na formatach plików do archiwizacji potracili zęby. Znamy też z oglądu na żywo czy z netu najważniesze sprawy związane z tą materią, ale cieszę się, że pomagacie i poddajecie wartościowe informacje.
Naszą piętą achillesową jest oprogramowanie. W tym momencie Apy (archiwa państwowe) pracują na rozproszonych bazach danych które zazebiają się informacyjnie ze sobą ale nie technicznie i często należy uzupełniać jedną informacje po koleji w kilku bazach jednocześnie. Nie będę też wspominał o komforcie pracy na Accesie oraz innych licencyjnych problemach... w każdym razie jeśli chodzi o problemy to można je mnożyć w nieskończoność. System główny z jakiego będą korzystać i archiwiści i userzy (przez wyszukiwanie informacji w zasobie APów) w pierwszej fazie powstanie ze scalenia i konwersji danych z baz accessowych. Bazy te zawierają w tym momencie ponad 5 milionów rekordów. No ale o tym szerzej w głównych założeniach...
Co będziemy udostępniać? Głównie opis wzbogacane obrazami - tak więc chyba, podkreślam chyba bittorrent nie będzie tu się sprawdzał.

Jak musimy składować aby było to zgodnie ze sztuką? Conajmniej dwie wersje plików jedna kopia matka w tiff (gdzie mamy doczynienia z formatem o znanej specyfikacji i bezstratnym) trafia do głównego archiwum NAC, druga użytkowa stanowi podstawę do dalszej pracy czy/i stanowi podstawę do wypuszczania kolejnych np. wglądowek (ze znakiem wodnym).

Jak będzimy trzymać dane w systemie? Osobno opisy materiałów archiwalnych (np. kto wytworzył, zawartość akt), osobno metadane obrazów (rozmiar, rozdzielczość) i osobno same obrazy.

Czy będziemy mirrorować? Tak w kilku archiwach w Polsce,

Czy Djvu będziemy używać? W tym moemencie nie wiem jeszcze, obawiam się tylko niecheci userów którzy będą musieli doinstalować coś aby oglądać djvu, i wciąż uważam, że to format dla biliotekarzy,

 to na tyle w tym miejscu - sukcesywnie będą się pojawiały nowe informacje o potrzebach projektach etc.będźcie w kontakcie!

pozdrawiam,

 Rafał

P.S. Patrząc na tego posta muszę czem prędzej zrobić FAQ NAC

[minder]

Rufus, co rozumiesz przez "format dla bibliotekarzy"? Przecież podobnie jak PDF został stworzony do przechowywania wszystkiego, co drukowane. Na djvu.pl są świetne przykłady map w tym formacie. Proponuję przełączyć widok na czarno-biały, by docenić ten format. Doszukałem się kiedyś przecudnych kopii starodruków w tym formacie. Fantastycznie zdobiony Koran zajmował kilka skromnych megabajtów. Same jpgi zajmowałyby kilkakrotnie więcej, podobnie z resztą jak pdfy. DjVu może tworzy się wolno, ale są pewne powody (z resztą, komu ja to tłumaczę? ). Wykonywane jest np. wydzielanie warstw danych i przeprowadzany jest OCR. Dzięki temu korzystanie z tak przygotowanych danych jest czystą przyjemnością, bo łatwo można wszystko wyszukać - w przypadku map jest dość pomocne, szczególnie że np. nazwy rzek mogą się wyginać wraz z rzeką, a i tak są rozpoznawane i udostępniane do szukania. Już nie wspominam o tym, że jakieś programy (np. kartograficzne czy CAD) mogłyby eksportować dane bezpośrednio w DjVu.

Wspomnianym już wcześniej kolejnym argumentem za DjVu jest rozmiar. Wczoraj trafiłem na stronę jakiegoś archiwum, gdzie różnica między plikami DjVu, a PDF była ~ sześciokrotna. Przy zwykłym tekście. Przy tekście z grafiką te różnice mogą być wręcz powalające. Do tego dochodzi jeszcze szybkość. Weźmy pliki djvu i pdf z taką samą zawartością, np. Biblią, i spróbujmy przejść ze strony tytułowej prosto do Apokalipsy. Ładnych "kilka" stron, prawda? Kto pracował z dużymi tekstami w pdf wie czym to skutkuje. Szczególnie na starszym sprzęcie. Jeszcze korzystniej DjVu wypada przy przeglądaniu przez sieć, bo nie musi być cały wczytany, by mieć możliwość skoku na koniec, bo każdą stronę można wczytać niezależnie.

Czekam na konkretne argumenty przeciwko DjVu. Tylko błagam, nie szybkość przerabiania czy stratność formatu. Stratność można sobie ustalić, a szybkość tworzenia jest niczym przy późniejszej wygodzie korzystania. Jeszcze kwestia wtyczki. Jak chcę oglądać filmiki/animacje Flash, to instaluję wtyczkę. Jak chcę czytać PDF, instaluję Acrobata. Chcę oglądać film kodowany w x264 czy Theora - instaluję kodeka. Dlaczego jak ktoś chciałby skorzystać z zasobów NAC, nie może sobie zainstalować wtyczki do DjVu? Naprawdę nie widzę problemu.

[Kazimierz Schmidt]

Reaktywując się na forum pozwolę sobie na kilka uwag:
przepraszam że wziąłem część z innego mojego postu który jest tu: http://www.lublin.ap.gov.pl/ifar/ifarforum2/index.php?topic=840.0
ale nie chce mi się jeszcze raz pisać.

w tej kwestii:

Bo jak ludzie będą archiwizować dobra kulturalne polskiej kinematografii i muzyki, to zostanie warezem z polskimi filmami i muzyką, przy okazji wymiatając mniejsze strony tego typu. Lekkie rozeznanie w tej materii mam i jeśli będą tutaj filmy to przyciągniecie rzesze piratów.
A teraz istotna rzecz:
Miejsce. Takie archiwa potrzebują znaczne ilości miejsca na dysku. Jaki macie pomysł na to? - Ten problem będzie wracał jak bumerang.

Otóż w Planie Informatyzacji Państwa
w części 7g PIP mamy:
"Opracowanie metodologii i prezentacji zasobów archiwalnych audio i wideo oraz udostępnianie ich na nośnikach informacji i przez Internet wraz z cyfryzacją zasobów archiwalnych" na co jest czas do grudnia 2009.
Co ważne, to zadanie wpisane jest z konkretnymi pieniędzmi w "Tabela 2. Zestawienie i charakterystyka sektorowych projektów teleinformatycznych" pt. PREZENTACJA I UDOSTĘPNIANIE ZASOBÓW ARCHIWALNYCH AUDIO I WIDEO.  na to w latach 2007-2010 ma być przeznaczone 97 mln zł (15 % budżet państwa, 85 % Europejski Fundusz Rozwoju Regionalnego). To zresztą pokazuje jaką siłę przebicia mają ... inni. Oby NAC dostało (dodatkowo do tego co dotąd ADM!) choć połowę tych środków co Filmoteka Narodowa...

W kwestii formatów plików, metadanych, zarządzania w długim czasie, jakości itd... tematów poruszanych w tym wątku
PIP nakłada także inne obowiązki:
"Tabela 1. Działania w zakresie rozwoju społeczeństwa informacyjnego" w części 7a:
"Opracowanie metodologii archiwizacji cyfrowej (digitalizacji) różnego rodzaju zasobów archiwalnych, bibliotecznych i muzealnych oraz innych dokumentacji związanych z zabytkami, a także sposobów udostępniania ich w wersji cyfrowej. " Plan zakłada że zdarzy się to do końca czerwca 2007 (a więc mamy już kwartał opóźnienia).
Przypominam, że pracuje nad tym Zespół ds Digitalizacji powołany przez MKiDN który ma taką strategię digitalizacji przygotować  - czyli odpowiedzieć na pytania co digitalizować i po co, a także w jaki sposób, za pomocą jakiego sprzętu, jakie wymagania techniczne dotyczące jakości (rozdzielczość, głębia bitowa, jakość koloru, częstotliwość próbkowania)  formatów, metadanych (technicznych, opisowych, administracyjnych i "behawioralnych") itd. Nie będę jednak wieszał na nim psów bo sam jestem członkiem a problem jest bardzo złożony...

Co do pracy zespołu roboczego w zakresie standardów metadanych opisowych to była krótka piłka:
bibliotekarze mówili MARC, archiwiści EAD, muzealnicy SSWIM, a niżej podpisany złożył zdanie odrębne.
Otóż jak pokazuje praktyka krzyżują się dwa podejścia a mianowicie
- takie które zajmuje się tylko digitalizacją tego co już jest w bibliotekach i archiwach
- i takie które dotyczy archiwizacji dokumentów elektronicznych powstałych w wyniku działania podmiotów zewnętrznych.
Na razie są to działania osobne ale planując digitalizacje materiału analogowego trudno nie dostrzegać także i tego, że jednocześnie powstają obiekty cyfrowe nie mające "tradycyjnego" pierwowzoru. Można też przypuszczać, że dla użytkownika archiwów i bibliotek w niedalekiej przyszłości nie będzie istotne czy informacja do której dotarł, powstała najpierw w postaci analogowej czy cyfrowej. Ważna będzie treść informacji, jej wiarygodność oraz możliwość szybkiego odnalezienia. I szlag go trafi jeśli dla dokumentów elektronicznych powstałych od razu w takiej formie będzie miał inne zasady wyszukiwania, dostępu itd a dla tych zdigitalizowanych - inne. Prędzej czy później więc trzeba będzie znaleźć wspólny mianownik dla dokumentów elektronicznych - niezależnie od ich pochodzenia. Oczywiście można olać problem i stwierdzić że jak dotąd "rekordy" złapane przez bibliotekę opisuje się w MARC21 a przez archiwum w ISAD(G) (dla wielu: czytaj EAD). Obojętnie czy jest to film w MPEG4 (obojętnie czy tak powstały in statu nascendi czy w wyniku digitalizacji) czy też "strategia informatyzacji RP" w PDF-ie czy zeskanowane listy Cypriana Kamila Norwida bibliotekarze opiszą to w MARC21 a archiwiści w EAD... Prawda, że to byłoby co najmniej dyskusyjne? Więcej na tym forum już o tym pisałem np. tu: http://www.lublin.ap.gov.pl/ifar/ifarforum2/index.php?topic=626.0

Co do pracy zespołu roboczego w zakresie standardów technicznych to po zebraniu materiałów dotyczących tego co robią inni okazało się, że nie ma tu jakichś najlepszych rozwiązań, które można po prostu wskazać. Oczywiście są i tacy którzy zdecydowanie opowiadają się za konkretnymi przykładami (celowo nie podam jakie żeby nie zaogniać).
Rzucę garść problemów:
Otóż w zakresie standardów technicznych ważna jest specyfikacja techniczna dotycząca nie tylko samych plików (to w miarę proste) ale także (a może  przede wszystkim) metadanych (technicznych, administracyjnych i behawioralnych).
Wszystko jest fajnie jak trzymamy nasze kopie cyfrowe uporządkowane np tak: jeden folder zawiera jedną pozycję książkową mającą 200 stron. Każda strona to osobny TIFF (wszyscy go kochają a więc i u nas tak będzie - zapomnijcie o PNG!). Skąd wiemy która jest która? Będziemy nadawać odpowiednie nazwy plikom?. Jeśli nie rozwiążemy tego problemu (metadane behawioralne) to nie da się automatycznie tworzyć np przeglądowych PDF-ów (czy jak kto woli DjVu). Tylko czy nasz "folder" będziemy w stanie utrzymać przez długo czas? A kto powiedział, że "foldery" w ogóle mają być ? A może po prostu zrobić to tak, że w każdym pliku zapisać metadane wskazujące do jakiej pozycji należy i jaka jest przed a jaka po... a może nie - tylko zapisać to w osobnym miejscu?

Oczywistym są postulaty żeby (tylko tam gdzie kolor lub odcienie szarości są ważne) skanować materiał wraz z wzorcem koloru lub szarości (jakim)? I tu pytanie: czy użytkownik cały czas ma widzieć ten wzorzec? Zwłaszcza w postaci przeglądowej mogłoby to go denerwować. A więc czy oprogramowanie NAC o którym tu już była mowa nie powinno umieć takiej "linijki" wycinać "w locie" przy przetwarzaniu masowym (wsadowym) do formatu przeglądowego? Przy okazji: może mi ktoś doradzi w jaki sposób ten wzorzec kłaść  (może na jakim "czerwonym suknie" -  w odróżnieniu od białego tła ... reszty tła) żeby oprogramowanie radziło sobie łatwo z "wycinaniem" wzorca? Inaczej będziemy mieli robotę głupiego dla ludzi. Robotę która kosztuje. Jeśli teraz pomyślimy nad standardowym tłem dla wzorca i standardowym miejscem jego umieszczania to może potem będzie taniej...

Kolejny problem to wiarygodność naszych skanów. I tu dochodzi problem tzw. "preservation metadata", które będą potrzebne aby pokazać historię powstania i przenoszenia danych... I te powinny być na zewnątrz obiektów cyfrowych które opisują, po prostu po to aby nie naruszać ich integralności.

Część metadanych technicznych z cała pewnością będzie zapisana bezpośrednio w plikach obrazów bez względu na to czy tego chcemy czy nie. Jeśli urządzenie będzie zapisywało w EXIF to z cała pewnością powinniśmy takie metadane zachować. Dla wiarygodności naszych kopii cyfrowych mogą to być istotne informacje a ich zachowanie nic nie kosztuje. Dlaczego jednak mielibyśmy to jeszcze wyprowadzać na zewnątrz? Wbrew pozorom to jest też ważne pytanie...
itd itp...
przepraszam ale może lepiej wrócę do pracy dla Zespołu ds Digitalizacji... bo tam trzeba coś konkretnego i do tego jeszcze wykonalnego zaproponować

aha, pewnie już tam byliście nie raz,  ale jeśli nie to rzućcie okiem tu:
http://www.loc.gov/premis/ (standard metadanych do długoterminowego przechowywania obiektów cyfrowych)
i tu
www.loc.gov/mix (standard matadanych technicznych do obrazów rastrowych - także norma NISO)
a potem koniecznie tu:
http://www.prov.vic.gov.au/vers/vers/default.htm (cała polityka przechowywania dokumentów elektronicznych)
i zobaczyć w samej specyfikacji metadanych która jest tu: http://www.prov.vic.gov.au/vers/standard/pdf/99-7-2_Std_ver2-0.pdf jakich elementów VERS nie uwzględnia a które były w "NAA recordkeeping metadata standard" wymienione...

jak jeszcze dołozymy doń to:
www.archives.gov/research/arc/digitizing-archival-materials.html
http://memory.loc.gov/ammem/about/techStandards.pdf
http://www.nla.gov.au/digital/standards.html
to zobaczymy jakże wiele spraw jest do ustalenia.

Oczywiście można podejść do problemu standardów jak Australijczycy z instytutu od Aborygenów:
http://www.aiatsis.gov.au/__data/assets/pdf_file/7034/Technical_Standards_inc_video_V8.pdf
krótko, węzłowato i na temat... no nie?
albo (jak zwykle w Polsce) poczekać na to co zrobią Amerykanie... czy też przetłumaczyć ogłoszony przed 3 laty materiał NARA i wskazać jako wskazówki obowiązujące....

i w takim otoczeniu działa (działać ma) NAC ))
trzeba życzyć powodzenia i wpisania do kolejnego planu informatyzacji państwa z kwotą nie mniejszą niż na Filmotekę Narodową - co niniejszym czynię.

[Rafał Rufus Magryś]

Minder,

 Chyba zastosowałem za duże uproszczenie - dla bibliotekarzy (ale nie tylko) bo ma całe mnóstwo "ficzerów" dla nich dobrych czyli właśnie OCR (niemożliwy w archiwach jakie mają w 85% zasób pisany ręcznie) warstwy (niejednorodne tła w archiwaliach generują kosmiczne problemy z ich wydobyciem). Z tego co się orientuje i co twórcy sami piszą na stronie Djvulibre (a więc wolnego Djvu): " Decoders and simple/experimental encoders are open sourced and included in DjVuLibre, but the best encoders (as of today) are owned by LizardTech Inc and kept proprietary". Pewnie w jakiejś części w NAC wykorzystamy zamknięte oprogramowanie (to nawet będzie zgodne z filozofią testowania nowych technologii) ale na razie nie możemy już na starcie korzystać z zamkniętego jeśli chodzi o wykorzystanie "przemysłowe" standardu... Możemy zrobić inaczej: pod egidą NAC powłać projekt optymalizacji i rozwoju Djvulibre, jeśli zbierzmyu grupę ludzi gotową się w to zaangażować...

Pozdrawiam

[Kazimierz Schmidt]

Rafale,
"projekt optymalizacji i rozwoju Djvulibre" brzmi tak ambitnie, że może tez warto zapytać czy takie zadanie realizowane "pod egidą NAC" w ogóle powinno być rozpatrywane? A może nie złapałem dokładnie o co chodzi?
Zgadzam się Minderem że "Jak chcę czytać PDF, instaluję Acrobata. Chcę oglądać film kodowany w x264 czy Theora - instaluję kodeka. Dlaczego jak ktoś chciałby skorzystać z zasobów NAC, nie może sobie zainstalować wtyczki do DjVu?"
Z całą pewnością format przeglądowy musi być nie tylko "lekki" ale też przede wszystkim dobrze rozpowszechniony. Po to żeby nie zostać z ręką w nocniku gdy okaże się że nie ma rynku wsparcia (bo nie ma już kodeków do zainstalowania które użytkownicy "sobie wezmą"). A wtedy trzeba będzie z takiego formatu uciekać. Bez względu na to czy rozwinęliśmy Djvulibre czy nie.

Jak się wydaje i PDF jest już wystarczająco rozpowszechniony, żeby nie musieć wchodzić w nieśmiertelnego JPEGa którym trudno się zarządza (bo aby prezentować cały dokument wielostronicowy trzeba wielu plików) i jest znacznie "cięższy". Z całą pewnością więc wsparcie dla PDF-a będzie więc i za 20-30 lat dostępne. Czy możemy to samo powiedzieć o DjVu? Porównując do formatów analogowych: w swoim czasie na rynku "przeglądowym" walczyły gorszy VHS i lepszy Hi8. Wygrał gorszy VHS. I dziś można go ciągle łatwo odtwarzać.
Jeśli nawet odpowiemy sobie na pytanie że DjVu jest już OK i ludzie go powszechnie używają to nie znaczy żeby samemu rozwijać DjVuLibre. Najpilniejszym zadaniem wydaje się bowiem oprogramowanie do zarządzania tym co wyprodukujemy. Oprogramowanie które poradzi sobie z najróżniejszymi metadanymi, a może nawet (jak sądzą niektórzy) będzie umiało jeszcze "wyczesać" metadane z plików TIFF (tak jak robi to np. JHOVE zob. http://hul.harvard.edu/jhove/ ) aby potem można było zarządzać nimi niezależnie od plików.

A swoją drogą dlaczego w najróżniejszych wskazówkach publikowanych przez duże instytucje jako format prezentacyjny ciągle króluje JPEG? Przyzwyczajenie? Zespoły wskazujące na zastosowanie tego formatu nie znały innych?

O DjVu nie pytam jednak bez kozery. Otóż trwają prace nad nowelizacją Rozporządzenia Rady Ministrów w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2005 Nr 212 poz. 1766). Do końca września trzeba przekazać do Departamentu Informatyzacji MSWiA propozycje zmian do obecnej wersji rozporządzeń (NDAP jest w rozdzielniku). Zajrzyjcie więc drodzy Forumowicze do załącznika 2 do tego rozporządzenia i zobaczcie co teraz jest wpisane do "danych zawierających informację graficzną" a co do "danych zawierających dokumenty tekstowe i tekstowo-graficzne". I tam nie ma DjVu. Czy przy okazji prac nad nowelizacją należy sugerować jego dopisanie? I jak to uzasadnić. I to nie jest takie sobie pytanie bo jeśli potem instytucja publiczna będzie oficjalnie stosować formaty niewymienione w rozporządzeniu to potem kontrola NIK-u stwierdzić może że niezgodnie z prawem coś jest robione.
Aha: jakby ktoś naprawdę kochał DjVu to w rozdzielniku jest też oprócz organów państwa także parę wyższych uczelni oraz: Stowarzyszenie PEMI, Krajowa Izba Gospodarcza Elektroniki i Telekomunikacji, Polska Izba Informatyki i Telekomunikacji, Polskie Towarzystwo Informatyczne, Polskie Towarzystwo Społeczenstwa Informacyjnego, ISOC Polska, Fundacja Wolnego i i Otwartego Oprogramowania, Koalicja na Rzecz Otwartych Standardów...
A więc pole do działania (czyli legalnego lobbingu na rzecz DjVu) jest bardzo szerokie.

[Venomous]

Witam,
według mnie, jeżeli jest taka możliwość, to DjVu powinno zostać dopisane do rozporządzenia w ramach nowelizacji. Nie jako przymusowe i obowiązujące, ale właśnie po to, że jeżeli wybierzemy ten format (co nie jest powiedziane), to w przypadku kontroli NIK lub innego organu kontrolującego nikt nam za to głowy nie urwie. O ile mi wiadomo, to PW korzysta (a przynajmniej korzystało w ubiegłym roku) z DjVu przy pracach nad obrazami w medycynie i wielu naukowców zdecydowanie podkreśla jego zalety w porównaniu z JPEG. Również moje badania do pracy magisterskiej wskazały na zalety tego formatu przy pracy ze skanami akt, jak również fotografii i innych dokumentów archiwalnych. Szybkość przetwarzania, jak również kwestie związane z wielkością plików mają istotne znaczenie w środowisku archiwalnym. Jedynym problemem była kwestia OCR, gdzie Lizard Tech. zastrzegł patenty dotyczące tworzenia warstwy tekstowej dla tych dokumentów. Nie wiem jak sprawa wygląda w chwili obecnej, ponieważ od ponad roku nie miałem już do czynienia z DjVu. Czy jest już jakiś mechanizm otwarty umożliwiający bezpośredni odczyt warstwy OCR z dokumentu? Jeżeli tak, to zajęcie się kwestią DjVu staje się według mnie koniecznością, która może pozwolić na oszczędności budżetowe związane z zakupami olbrzymich macierzy oraz jeszcze większych bibliotek taśmowych. Myślę, że wykorzystując DjVu takie koszty można zmniejszyć nawet czterokrotnie, co przy obecnych cenach sprzętu ma chyba spore znaczenie.

[MariuszB]

Przede wszystkim, jako że to moja pierwsza wypowiedź na tym forum, witam wszystkich bardzo serdecznie.
Pomysł stworzenia archiwum w konwencji Open Source wydaje mi się bardzo interesujący i bardzo chętnie się weń włączę. Nie przeczytałem jeszcze wszystkich Waszych wypowiedzi, więc wybaczcie, jeżeli w jakiejś kwestii się powtórzę. Bardzo interesuje mnie kwestia, jaki jest plan techniczny składowania tych wszystkich danych. Uważam, że przy takiej objętości i różnorodności jest to naprawdę dużym wyzwaniem. Zarówno baza, jak i technologia składowania plików, muszą być zoptymalizowane pod kątem odczytu. Czy istnieją już jakieś założenia dotyczące tych technologii?

[Kazimierz Schmidt]

Muszę się poprawić bo trochę za bardzo "pojechałem" z tym NIK-iem. Otóż MSWiA w specjalnym Komunikacie objaśniło, że:
" W związku z pojawiającymi się mylnymi interpretacjami Rozporządzenia Rady Ministrów w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz. U. Nr 212 poz. 1766 z dnia 28 października 2005r.) dotyczącymi możliwych do stosowania formatów plików dokumentów tekstowych i tekstowo-grafcznych, Ministerstwo Spraw Wewnętrznych i Administracji informuje, że rozporządzenie to określa jedynie minimalne wymagania.

Oznacza to, że podmioty podlegające zapisom ustawy z dnia 17 lutego 2005r. o informatyzacji działalności podmiotów realizujących zadania publiczne są obowiązane do stosowania zawartych w rozporządzeniu formatów danych, natomiast nie ogranicza ono w żaden sposób możliwości korzystania z innego rodzaju formatów plików dokumentów tekstowych i tekstowo-graficznych. Rozporządzenie to wskazuje również na kilka równoważnych formatów i nie narzuca ani nie preferuje w żaden sposób któregokolwiek z nich"

Tak więc na podstawie tego można zrozumieć, że DjVu w rozporządzeniu będzie oznaczać, że podmioty publiczne będą obowiązane do stosowania m.in DjVu. Tj. nie do tego żeby DjVu stosować do tworzenia  wersji przeglądowych ale tylko do tego aby umiały DjVu "wyprodukować" i "odczytać". Praktycznie rozumiałbym to jako przymus prawny do tego żeby (jeśli użytkownik by sobie zażyczył otrzymać nie w JPG tylko w DjVu to trzeba byłoby mu tak dać). Chyba że format uznany byłby jako "tylko do odczytu" - warto zauważyć że PDF i doc. są w obecnej wersji rozporządzenia są właśnie "wyłącznie do odczytu" a więc archiwum nie musi umieć ich "produkować" a jedynie odczytać.
Jeśli więc nie będzie DjVu w rozporządzeniu to też nic się nie stanie... no chyba żeby pojawiła się kolejna interpretacja.

Ale i to niekoniecznie tak będzie ponieważ nie wiadomo w którą stronę zmiany w rozporządzeniu w ogóle pójdą. Być może w ogóle nie będzie listy formatów?

Dziękuję

[Kazimierz Schmidt]

I to ja napisałem bezsensowne "Dziękuję" na koniec poprzedniego postu?
Dobrze, że nie co innego... Jak bym się wtedy wytłumaczył, że nie przypominam sobie... Widać jak mnie zamroczy to kulturalne rzeczy wypisuję.
Czas się chyba wybrać do lekarza.
Albo robić zrzuty ekranów...