Autor Wątek: Projekt nr 2. Webowy program do przetwarzania plików graficznych,  (Przeczytany 13573 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

Offline Rafał Rufus Magryś

  • Administrator
  • st. kustosz(ka)
  • *****
  • Wiadomości: 1333
  • Płeć: Mężczyzna

 Witam

Szerze powiedziawszy ten projekt może Wam się wydać bardzo znajomy w odniesieniu do tego tematu: http://www.lublin.ap.gov.pl/ifar/ifarforum2/index.php?topic=878.0 Oczywiście to częsciowo prawda ale ma trochę inny cel. Projekt nr 1, ma służyć do zainstalowania na komputrze lokalnym, projekt nr 2 ma pomóc w przetwarzaniu danych na zasadzie klient-serwer - na serwerze po uploadowaniu...  Ten fragment będzie można wykorzystać bezpośrednio jako moduł, element w systemie wspomagącym zarządzaniem obiektami jakie mają być prezentowane przez NAC. I po stronie usera i po stronie archiwum...

Tym razem dojdą jeszcze kolejne opcje:

Potrzeba: Program do masowej konwersji plików graficznych w wersji klient-serwer,

Zakładane funkcjonalności:


-wsadowa obróbka plików graficznych ("n" plików w kolejce),
-obróbka dużych plików tiff wielkości 400 mb to nic szczególnego (średnie pliki 50-60 mb tiff),
-format wyściowy: tiff,
-docelowy: jpeg, png, mniejszy tiff etc.
-możliwość dodawania znaku wodnego (ważne dla dystrybucji plików przez archiwa),
-zmiana rozmiaru plików,
-zmiana rodzielczości,
-zmiana kontrastu/jasności,

te funcje programu narzędziowego można połączyc z przeglądarką plików:

- przybliżanie oddalanie ,
zmiana kontrastu/jasności
- wycinanie danego obiektu do dalszego zapisu (później  w systemie na koncie użytkownika, przesyłanie wybranych obiektow na konto pocztowe użytkownika.

Pomysł na realizację:
jakaś technologia sieciowa - java, php, python(?) tu bardzo chętnie skorzystam z Wazej porady :)..
w tym momencie szukamy kilku osób 2-3 żeby na podstawie danych dostarczonych przez archiwistów wyspecyfikowały produkt i zrobiły jakieś wstępne wyliczenia terminu realizacji.

Pozdrawiam,

Rafał
Rafał "Rufus" Magryś
...patience is a virtue...

Offline piotrpsz

  • słuchacz(ka)
  • Wiadomości: 10
  • Płeć: Mężczyzna
    • beesoft.org
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #1 dnia: Wrzesień 13, 2007, »
Z tego co rozumiem przetwarzanie plikow bedzie po stronie serwera? Czy nie?

Jesli tak, to na serwerze bedzie mozna posadzic ten sam engine do przetwarzania obrazow, ktory bedzie w programie desktopowym.

pozdrawiam
piotr

Offline minder

  • słuchacz(ka)
  • Wiadomości: 5
  • Płeć: Mężczyzna
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #2 dnia: Wrzesień 13, 2007, »
Tak jak już to zostało napisane w innym wątku - wrzucić ten sam silnik oparty na ImageMagick i Pythonie, do tego interfejst graficzny na desktop lub tekstowy na serwer. Oczywiście aplikacja graficzna mogłaby się łączyć poprzez sieć z serwerem - to przecież nie jest problem.

Aż mi się przypomniała Amiga i język AREXX (pochodna popularnego na serwerach klasy mainframe języka REXX), który po prostu idealnie nadawał się do wykonywania tego typu zadań i był (jest) diabelnie szybki. Python bardzo REXXa przypomina, więc osobiście postuluję właśnie ten język.

Tak swoją drogą - proszę podać główne różnice między programem desktopowym a serwerowym. Czy nie lepiej by było, gdyby na desktopie skanować i wykonywać wstępną normalizację (kontrast, jasność, nasycenie, etc.), wynik przesyłać na serwer i tam już robić wszelkie hocki-klocki, które nie wymagają wizualnej kontroli nad obrazem? Wszystko mogłoby się odbywać z jednej aplikacji.

Załóżmy, że mamy pracownię archiwistyczną, 100 skanerów z obsługą, która pieczołowicie wprowadza nowy materiał. Bieżąca korekta polega na kadrowaniu i dobieraniu parametrów, by rezultat był możliwie wierny oryginałowi. Potem każde stanowisko wrzuca (to już robi skrypt po zaakceptowaniu skanu) plik w odpowiednie miejsce na serwerze i stamtąd już pobiera go automat. Na końcu drogi warto by było posadzić kilku weryfikatorów sprawdzających rezultat oraz ze dwie osoby do rozwiązywania nagłych problemów technicznych. Dla bezpieczeństwa można założyć, że pliki pobrane ze stanowisk byłyby przechowywane na serwerze przez jakiś czas (np. tydzień) w razie gdyby mimo wszystko trzeba było się do nich odwołać.

Na metodach archiwizacji się zbytnio nie znam, ale chodziło mi o przedstawienie możliwego "workflow".

Offline Rafał Rufus Magryś

  • Administrator
  • st. kustosz(ka)
  • *****
  • Wiadomości: 1333
  • Płeć: Mężczyzna
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #3 dnia: Wrzesień 14, 2007, »
Witam,

 Przy tym projekcie nie mówimy tylko o NAC (gdzie póki co nie ma 100 skanerzystów jeszcze) owszem Minder - przy takim założeniu jest wszystko ok. Ja mówię o innych instytucjach ochrony dziedzictwa kulturowego np. małych biblioteczkach, mniejszych archiwach kościelnych, archiwach regionalistów etc. i tam w miarę ich skromnych możliwości mają jakiś skanerek i starają się zdigitalizować żeby tylko udostępnić użytkownikowi to co jest najcenniejsze z ich zasobu. Aplikacja standalone to dla nich właśnie i jeszcze dla częsci apów co nie mają odpowiedniej sieci albo serwera odpowiedzialnego za przetwarzanie plików. Możnaby i u nich instalować np. na WAMPie albo na Krasnalu (pod windą) serwerek ale to nie zawsze działa jak powinno(serwerki instalowane z paki) a nasz program ma wzbudzać zaufanie do środowiska open source i do NAC.
Co do podanego workflow - to w części masz rację i super że nas przejrzałeś ;)...chciałem aby webowa aplikacja była możliwa do wykorzystania w głównym systemie workflow digitalizacyjnego - jego opis pojawi się wkrótce jako kolejny projekt :)...

Pozdrawiam,
Rafał "Rufus" Magryś
...patience is a virtue...

Offline Michał Sawicz

  • słuchacz(ka)
  • Wiadomości: 8
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #4 dnia: Wrzesień 23, 2007, »
Z tego, co tu napisane, wychodzi mi, że aplikacja ta miałaby działać przez przeglądarkę. Moim zdaniem nie jest to najlepszy pomysł (szczególnie gdy mowa np. o plikach 400MB). Przeglądarki nie mają mechanizmów sprawdzających poprawność wysyłanych (a właściwie to serwer - odebranych, bo przeglądarka nie wysyła żadnych dodatkowych informacji) danych, nie ma możliwości sprawdzenia, na jakim etapie jest wysyłanie.

Wydaje mi się, że najlepszym rozwiązaniem byłoby rozszerzenie programu z projektu nr 1 o możliwość współpracy z jakąś aplikacją na serwerze - tam aplikacja posiadająca kolejkę obrazów do przetworzenia, raportując postęp prac użytkownikowi (-om), wykonywałaby polecenia zadane przez użytkownika siedzącego przy identycznym interfejsie jak by pracował lokalnie - właśnie kadrowanie, obracanie, dopasowanie kolorów itd. na jakimś podglądzie i wysłanie zadania (informacji, co z danym obrazem trzeba zrobić) z całym plikiem na serwer. (Jak jeszcze raz przejrzałem post @minder - to właśnie o tym pisał) Tutaj prędzej zgodziłbym się na wykorzystanie pythona (widzę zwolennika ;)), ale też nie jestem pewien, czy jest to najlepszy pomysł, kiedy mamy pod ręką Piotra, który chce pomóc. Łączenie aplikacji, które w całej swojej idei miały pracować jako tandem, pisanych w dwóch różnych językach, wydaje mi się niepotrzebne.

Należałoby za to przede wszystkim zdefiniować sposób komunikacji z serwerem, tak by każdy mógł napisać własny program działający po stronie klienta, który będzie mu bardziej pasował (np. zintegrowany z jakimś innym systemem - bibliotekarskim czy jakimkolwiek innym), a dopiero potem połączyć te dwa do kupy.

Wykorzystanie technologii stricte webowej (przeglądarka, po drugiej stronie - najłatwiej PHP) widzę stosowne tylko przy udostępnianiu zasobów, nie dla ich przygotowywania. W przeglądarce nie ma wystarczających możliwości, aby dało się dobrze przygotować zadanie dla serwera. Za to jest to doskonały sposób na przedstawienie zasobów "szerszej publiczności" gdyż nie muszą oni wtedy męczyć się z aplikacjami, których nie znają.

Poruszony też został problem przechowywania danych już na serwerze - trzeba dobrze przemyśleć, jak to ma działać, bo składowanie x-set tysięcy obrazów bez ładu i składu nie ma moim zdaniem sensu - to, gdzie dany skan ma trafić, musi być zdefiniowane przez użytkownika w momencie uploadu - żeby nie poleciał on do jakiegoś kąta, w którym nie powinien się w ogóle znaleźć - i żeby można go było odszukać wg jakichś kryteriów (te podejrzewam są już jakoś zdefiniowane - trzeba za to pamiętać, żeby zaimplementować te kryteria dla naszych potrzeb). Widzę tu tylko problem - do tych kryteriów pewnie ktoś, gdzieś ma jakieś prawa. Jeśli chcemy na poważnie opublikować ten system jako Open Source (trzeba też wybrać licencję - jest z czego wybierać), nie możemy sobie podłożyć jakiejś świni wykorzystując coś, co łamie nie tylko licencję tego, czego użyliśmy, ale także tej licencji, którą wybierzemy do tego projektu.

Przepraszam, że trochę sobie przywłaszczyłem projekt, pisząc, że coś czy czamtoś zrobimy "my" ale nie chcę pisać "wy", bo to chyba nie o to chodzi.

Pozdrawiam serdecznie i zapraszam do dyskusji :)

Offline Rafał Rufus Magryś

  • Administrator
  • st. kustosz(ka)
  • *****
  • Wiadomości: 1333
  • Płeć: Mężczyzna
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #5 dnia: Wrzesień 25, 2007, »
Witam,

 Bardzo dziękuję za te uwagi do NASZEGO projektu. Właśnie tak powinno być jest "nasz" i jak go najlepiej zaprojektujemy i przedyskutujemy -tym lepiej będzie działał.
O przeglądarce myślę wciąż w kontekście małych instytucji kulturalnych w których osoby boją się czegokolwiek instalować, pzeglądarka moglaby też ułatwić sam proces instalacji nowego konta a głównym Systemie. Ale prawda jest taka o jakiej pisał Michał S. czyli brak możliwości sprawdzania przez przeglądarkę uploadu. Możnaby to jakoś łatać tzn. np przez porównywanie przez skrypt obrazka wyjściowego z tym przesłanym (rozmiary) ale to jest wg mnie łatanie a nie rozwiązanie. Stąd myślę, że chyba trzeba pójść w stronę czegoś z JAVA - i uruchomianego przez usera przez aplikację. Aplikacja ta mogłaby łączyć się z systemem głównym i wykonywać, monitorować etc. aplikacje na serwerze. Taka aplikacja może monitorować stan przesyłania a w razie problemu przetrzymywać część danych ofline i synchronizować po uzyskaniu połączenia co jest istotne w przypadku malutkich archiwów gdzieś w Polsce.
Problem składowania skanów jest w tym momencie rozpatrywany tak sam jak problem licencji. Myślę, że niedługo będę mógł się podzielić pomysłami na rozwiązania tych kwestii na forum :)...


Pozdrawiam,
Rafał "Rufus" Magryś
...patience is a virtue...

Offline Michał Sawicz

  • słuchacz(ka)
  • Wiadomości: 8
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #6 dnia: Wrzesień 25, 2007, »
Wydaje mi się, że właśnie odpalanie czegoś w przeglądarce (tym bardziej, jeśli jest to aplet javowy) może spowodować więcej zgonów niż nieduży programik, który przecież "instalacji" jako takiej nie musi wymagać. Wystarczy go rozpakować - oczywiście przyda się graficzny interfejs instalacji.
Javę też trzeba zainstalować, do tego jak dobrze pamiętam - po angielsku, a prędkość działania czegoś takiego apletu należy podzielić przez 10 w stosunku do natywnej aplikacji pisanej w C++. Pamiętajmy o tym, że takie właśnie nieduże instytucje nie będą miały komputerów, które mogą sobie pozwolić na marnowanie mocy na uruchomienie maszyny java.
Ale chyba czegoś jeszcze nie rozumiem - chodzi o to, by taka biblioteka mogła "wykorzystać" serwer do obróbki obrazu i odebrać 'gotowy' plik? Czy chodzi o scentralizowanie miejsca przechowywania?
Myślałem, że w aplikacji klient-serwer chodzi właśnie o zebranie efektów mocy przerobowej kilku(-nastu, -dziesięciu) osób, a projekt 'standalone' miałby właśnie służyć niewielkim podmiotom...

Offline Michał Sawicz

  • słuchacz(ka)
  • Wiadomości: 8
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #7 dnia: Wrzesień 26, 2007, »
Sorki za post pod postem, ale nie ma edycji...

Naszły mnie takie trzy pomysły po drodze do pracy:
1) Komunikacja między klientem a serwerem - wydaje mi się, że najlepiej będzie oprzeć ją na XMLu, najłatwiej wtedy będzie zdefiniować, jak np. 'zadanie' ma wyglądać. Nie jestem tylko pewien, czy sam plik opinać XMLem (po zakodowaniu base64 czy czym tam innym) czy wysyłać osobno. Pozwoli to osobom 'trzecim' na napisanie np. prostszego, lub wręcz przeciwnie - bardziej rozbudowanego interfejsu użytkownika czy z drugiej strony - wykorzystanie istniejącego interfejsu i podpięcie go do własnej aplikacji serwerowej. Powinna być też możliwość komunikacji po SSL, bo nikt nie zabroni ludkom używać tego przez internet, a raczej nie o to chodzi, żeby przesyłane do watermarkowania obrazki można sobie było po drodze przejąć. Można też pomyśleć o ewentualnej kompresji - jasne, że w przypadku TIFFa (z LZW lub podobnym) nie ma to wielkiego sensu, ale zdarzy się na pewno przesyłka BMP lub TIFFie bez kompresji - wtedy prosta kompresja na trasmisji może być przydatna.
2) Nic ważnego - ale może być przydatne - sprawdzenie prędkości transmisji przy połączeniu z 'serwerem'. Pani Kasi może nie wydawać się dziwne, że chce wysłać 400MB TIFFa po łączu modemowym. Jeśli nie będzie żadnej furtki, program się wykrzaczy prędzej czy później (tu kolejna sprawa - trzeba pomyśleć nad wznawianiem transmisji po jej zerwaniu) i Pani Kasia pobiegnie z krzykiem, że ona tego nie chce. Proste przesłanie kilkudziesięciu (lub -set) kilobajtów losowych znaków pozwoli nam określić, jakie są możliwości łącza - potem można ostrzec Panią Kasię, że transmisja tego pliku zajmie około 2 lata i czy na pewno chce to zrobić ;)
3) Zapomniałem... jak mi się przypomni, dopiszę.

Offline Michał Sawicz

  • słuchacz(ka)
  • Wiadomości: 8
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #8 dnia: Wrzesień 26, 2007, »
3) Przypomniało mi się ;) Myślałem też o wersjonowaniu dodawanych archiwów... Wiemy wszyscy dobrze, jak łatwo klika się gdzieś niechcący usuwając jakiś obiekt, a potem głowimy się nad jego odzyskaniem. Może system przechowania sporządzić na zasadzie przyrostowej (lub bardziej - przedrostowej - tak by aktualna wersja trzymana była w pliku, a różnicowymi można było dojść do każdej poprzedniej wersji), choć to już dalsze plany, ale na początek - po prostu zapisywanie każdej kolejnej wersji pliku z możliwością podglądu, jak wyglądały poprzednie (oczywiście możliwość całkowitego usunięcia / zastąpienia też powinna być zaimplementowana, ale trudniejsza niż po prostu nadpisanie poprzedniego pliku).

Offline Tuptus

  • słuchacz(ka)
  • Wiadomości: 10
    • Jazz Linux
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #9 dnia: Wrzesień 26, 2007, »
(oczywiście możliwość całkowitego usunięcia / zastąpienia też powinna być zaimplementowana, ale trudniejsza niż po prostu nadpisanie poprzedniego pliku).

O ile się orientuję to każdy system obsługujący wersjonowanie umożliwia cofnięcie się do dowolnego momentu w tym również przywrócenie skasowanych plików. Informacje o takich plikach przecież pozostają w informacjach o kolejnych wersjach. Inną sprawą jest kwestia rozmiaru takiego repozytorium.
Celuj w niemożliwe a osiągniesz nieprawdopodobne.

Offline Wojciech Woźniak

  • st. kustosz(ka)
  • ******
  • Wiadomości: 1132
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #10 dnia: Wrzesień 27, 2007, »
Witam
Wydaje mi się, ze nie ma sensu myśleć o wersjonowaniu (ufff!) plików. Z tego co sie orientuję (proszę o korektę jeśli coś kręcę!) przechowywać będziemy nietknięty plik wzorcowy w formacie tiff, natomiast obróbce będziemy poddawać obrazy w celu ich prezentacji. Co oznacza, że zawsze będziemy mogli sięgnąć do nietkniętego oryginału. Nie ma chyba potrzeby zajmować więcej miejsca kolejnymi wersjami tego samego pliku w różnych stadiach obróbki.
Sometimes you eat the bear
and sometimes the bear eats you

Offline Michał Sawicz

  • słuchacz(ka)
  • Wiadomości: 8
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #11 dnia: Wrzesień 27, 2007, »
Cytuj
to każdy system obsługujący wersjonowanie umożliwia cofnięcie się do dowolnego momentu
To zależy od przyjętych założeń, 'wersjonowanie' to bardzo szerokie pojęcie.
Cytuj
nietknięty plik wzorcowy w formacie tiff
No tak - wersja 1 - ale czy przechowywać go będziemy gdzie indziej? Nie chodzi mi też o wersje 'w różnych stadiach obróbki' ale np. wersje dla prezentacji na www (w różnych zresztą rozmiarach), albo do prezentacji w jakimś innym interfejsie, który może kiedyś powstanie.

Zaznaczam, że nie upieram się - poddaję pod dyskusję :)

Offline Wojciech Woźniak

  • st. kustosz(ka)
  • ******
  • Wiadomości: 1132
Odp: Projekt nr 2. Webowy program do przetwarzania plików graficznych,
« Odpowiedź #12 dnia: Wrzesień 27, 2007, »
Witam
Cytat: Michał Sawicz
Nie chodzi mi też o wersje 'w różnych stadiach obróbki' ale np. wersje dla prezentacji na www
To rzuca nowe światło na tę kwestię ;) Takie wersjonowanie wygląda zachęcająco: możliwość szybkiego dotarcia do wersji pliku pełniącej określone funkcje. Wobec tego cofam swoje wątpliwości.
Sometimes you eat the bear
and sometimes the bear eats you