Jaki jest obecny stan obsługi oprogramowania dla JPEG-2000?

Ogólne zalecenie rejestrowania oryginalnych zeskanowanych obrazów brzmiało: „użyj TIFF”. Ale programiści potrzebują ewolucji formatu do „ewolucji oprogramowania” i muszę rozwinąć swój system, aby przejść z TIFF na JP2.

Mam duże miejsce do przechowywania obrazów (terabajty) dla legalnych i naukowych zeskanowanych materiałów, potrzebują oryginalnego nagrania. Korzystam z niektórych reguł buforowania, ale system musi pokazywać (poprzez pobieranie z Internetu) lub manipulować (ImageMagick i innymi) oryginalnymi danymi.

Przeczytałem artykuł o migracji pamięci obrazów z TIFF-bezstratnej do JPEG-2000-bezstratnej, a wnioskiem jest pozostanie przy TIFF. Jednak artykuł pochodzi z 2009 roku i w tym czasie okazało się, że obsługa formatu JPEG-2000 przez dostępne oprogramowanie była bardzo słaba. Konwersje do JPEG-2000 były stratne w testowanym oprogramowaniu, a dostępne oprogramowanie do konsumpcji obrazów nie obsługiwało dobrze tego formatu.

Czy teraz jest czas na zmianę z TIFF na JP2, czy nie? Czy obsługa oprogramowania jest nadal tak samo wadliwa jak w 2009 roku?

W oparciu o listę aplikacji Wikipedii wsparcie w tych dniach wygląda całkiem nieźle. Zyskuje także popularność w organizacjach archiwizujących na całym świecie:

• Oto strona omawiająca między innymi jego przyjęcie przez NATO.

• Ten artykuł wspomina, że ​​Harvard University Library również przechodzi na JPEG-2000.

• Ten artykuł szczegółowo opisuje wysiłki British Museum i Harvard oraz dodaje Wellcome Digital Library.

Na moim MacBooku Pro z systemem 10.7.5 oto kilka wyników przeglądarki ( źródło 1 , źródło 2 ):

• Safari: bez problemu

• Chrome: czasami potrzebny do załadowania QuickTime

• Firefox: bez problemu

Nie testowałem IE, ale z tych trzech i z Wikipedii myślę, że obsługa JPEG-2000 jest teraz powszechna.

Jeśli chodzi o kwestię, czy należy przełączyć się, ponieważ wydaje się, że JPEG-2000 ma teraz wystarczającą obsługę platformy, zmieniłbym się tylko wtedy, gdy istnieją ku temu poważne powody techniczne:

• mniejsze rozmiary obrazu

• szybsza wydajność

• więcej Ochrony

• TIFF zaczyna być nieobsługiwany.

Jeśli zdecydujesz się na zmianę, prześlij nam ponownie swoje doświadczenia!

Myślę, że odpowiedź zależy od tego, czy kwestionujesz rzeczywiste użytkowanie lub zasięg wsparcia biblioteki. Ponieważ pytasz na programmers.stackexchange, może masz na myśli bibliotekę, ale wydaje się, że wszyscy zakładają, że pytasz o aplikacje. Pójdę za tłumem.

Mówiąc o aplikacjach, w oparciu o listę aplikacji Wikipedii, wsparcie w dzisiejszych czasach wygląda całkiem źle. Zgodne z nim oprogramowanie użytkownika jest ponumerowane i zwykle jest profesjonalnym narzędziem, a zyskuje na popularności w niektórych światowych organizacjach zorientowanych na archiwizację, które można dokończyć na jednej stronie. Krótko mówiąc, jp2 jest poza zasięgiem ludzi. W tym tempie nigdy nie osiągnie progu rentowności dla publicznej akceptacji, pomimo technicznej przewagi.

Mówiąc o przeglądarkach, Wikipedia podała, że ​​tylko Safari ma natywne wsparcie. Wszystkie inne, Firefox, Chrome, IE ... nie, z wyjątkiem niektórych z QuickTime, którego nie można zagwarantować w systemie Android / Windows i nie ma go w systemie Linux.

Na moim OpenSUSE 13.1, oto niektóre wyniki przeglądarki z przykładami (pamiętaj, że otwarcie przykładowej strony nie liczy się do OK, musisz otworzyć w niej obrazy .jp2):

• Chromium 33: Nie można tego zrobić, zaoferuj użytkownikom pobranie.
• Firefox 27: nie można tego zrobić, zaoferować użytkownikom pobranie.

(Ponieważ sam Linux obsługuje jp2, użytkownicy mogą otwierać obrazy po pobraniu)

** Edytuj po przeczytaniu komentarza Petera Kraussa ** Być może w kontekście konserwacji możesz wybrać format, ponieważ zwykle dostarczasz użytkownikom narzędzia; środowisko pulpitu i przeglądarki użytkowników ma drugorzędne znaczenie.

Ewolucja oprogramowania nie oznacza akceptacji najnowszego standardu technologicznego. Najnowszy standard technologiczny to nadzieja na przyszłą technologię komitetu standardowego, a ludzie głosują pieszo po swojej decyzji. Przykłady: Wiele migrowało do XHTML, a następnie HTML5, podczas gdy większość z HTML4 bezpośrednio do HTML5, a wiele migrowało do FireWire (1394), a następnie eSATA i USB3, a większość z USB2 bezpośrednio do USB3.