Autor Wątek: Projekt programu do masowej obróbki plików graficznych - program do instalacji  (Przeczytany 37054 razy)

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

Offline Rafał Rufus Magryś

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

 Zgodnie z zapowiedzią (po sugestii forumowiczów) rozbijania informacji na projekty chciałbym opisać pierwszy pomysł na program który jest potrzebny dla NAC ale jednocześnie przyda się wszystkim zainteresowanym masową obróbką plików o dużych rozmiarach. System ma umożliwić przetwarzanie plików graficznych w celu ich udostępniania na stronach www archiwów. Ważną sprawą jest wprowadzanie znaku wodnego aby archiwalia nie były wykorzystywane w celach komercyjnych (za czym powinna stać odpowiednia opłata - przeznaczna m.in na kolejne projekty digitalizacji).

Potrzeba: Program do masowej konwersji plików graficznych w wersji do instalacji lokalnej,

Wymóg: opensource na wszystkie platformy (winda, linux, mac os), optymalizacja w celu osiągnięcia największej prędkości przetwarzania plików,

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,

Pomysł na realizację:

Wydaje mi się, że realizację można oprzeć o imagemagick (dostępny na wymienione wyżej platformy). To pozwoli wykorzystać ten ogromny kombajn do naszych celów i pisać tylko samo gui - co zwiększy prędkość implementacji (po potrzeba jest duża). Za imagemagick przemawia też dobrze udokumentowane API.
Ewentualnie do projektu można też włączyć rozwój opendju (format djvu) a więc projekt mógłby korzystać z dwóch silników i generować pliki również w DjVu (ważne dla bibliotek).
Realizacja mogłaby nastąpić np. w gtk2 - (gotowe komponenty) ale się nie upieram i liczę na opinię.
Przy okazji tego małego projektu mam nadzieję, że okrzepną metody komunikacji ze środowiskiem "openowym", pojawią się też osoby zainteresowane ściślejszą współpracą. W stosunkowo prosty sposób będzie można uzyskać produkt jaki można będzie wskazać jako pierwszy udany efekt kooperacji archiwistów i open source.


Pozdrawiam,

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

Offline piotrpsz

  • słuchacz(ka)
  • Wiadomości: 10
  • Płeć: Mężczyzna
    • beesoft.org
Odpowiedz z propozycja w drodze (email);

pozdrawiam :)
piotr

Offline piotrpsz

  • słuchacz(ka)
  • Wiadomości: 10
  • Płeć: Mężczyzna
    • beesoft.org
Odpowiedz z propozycja w drodze (email);

Niedoszlo :) wiec zamieszce tutaj.

Wiec tak. Moge napisac ten program. Proponuje jednak biblioteke Qt.
Wynika to z tego, ze jest przenosna, szybka i w pelni obiektowa (co nie
dotyczy gtk, jesli nie chce sie uzywac wraperow).

Napisanie programu GUI nie jest zadnym problemem.
Jestem specjalista od szybkosci :)
(Beesoft Commander zdobyl zwolennikow wlasnie za szybkosc, no i zawodowo
zajmuje sie systemami czasu rzeczywistego.)

Rozumiem ze imagemagic bylby wywolywany wsadowo do wykonania zadania.
Nie znam imagemagic'a. Ale chyba by mnie ktos w tym wsparl.
Tylko uwaga: kazde wywolanie zewnetrznego programu to kupa czasu.
Chyba docelowo jednak trzeba by miec wlasne biblioteki. Jesli ma byc
szybko.

pozdrawiam
piotr

Offline Jan Szczygieł

  • słuchacz(ka)
  • Wiadomości: 6
Moim zdaniem zagonienie jakiegokolwiek kombajnu spowoduje że taki soft będzie bardzo zasobo żerny. Są to bardzo proste operacje na plikach i dlatego moim zdaniem jedynym sensownym rozwiązaniem aby takie oprogramowanie pracowało szybko i niezawodnie oraz miało suport (bo konieczne będą zmiany) jest zlecenie napisania takiego softu profesjonalistom, którzy kodują na poziomie np. C++.

Offline piotrpsz

  • słuchacz(ka)
  • Wiadomości: 10
  • Płeć: Mężczyzna
    • beesoft.org
Cytuj
Rozumiem ze imagemagic bylby wywolywany wsadowo do wykonania zadania.
Nie znam imagemagic'a. Ale chyba by mnie ktos w tym wsparl.
Tylko uwaga: kazde wywolanie zewnetrznego programu to kupa czasu.
Chyba docelowo jednak trzeba by miec wlasne biblioteki. Jesli ma byc
szybko.

Wlasnie wszedlem na strone ImageMagic i sie okazalo ze jest gotowana biblioteka Magick++.
Czyli wszystko co trzeba jest :)

piotr

Offline piotrpsz

  • słuchacz(ka)
  • Wiadomości: 10
  • Płeć: Mężczyzna
    • beesoft.org
Moim zdaniem zagonienie jakiegokolwiek kombajnu spowoduje że taki soft będzie bardzo zasobo żerny. Są to bardzo proste operacje na plikach i dlatego moim zdaniem jedynym sensownym rozwiązaniem aby takie oprogramowanie pracowało szybko i niezawodnie oraz miało suport (bo konieczne będą zmiany) jest zlecenie napisania takiego softu profesjonalistom, którzy kodują na poziomie np. C++.

Jestem zawodowym programista C++ (systemu czasu rzeczywistego, komputery pokladowe dla samochodow).

piotr

Offline minder

  • słuchacz(ka)
  • Wiadomości: 5
  • Płeć: Mężczyzna
Posłałem odpowiedź na mejl zanim moje konto zostało aktywowane. Program już istnieje i nazywa się ImgWorks. Według opisów i skrinszotów odpowiada wymaganiom. Interfejs na GTK+ (v. 1), ale to chyba najmniejszy problem. W razie jakby czegoś brakowało, to kod jest ogólnodostępny :D

Poza tym myślę, że można by się skontaktować z analogicznymi ekipami w innych krajach. Myślę, że Niemcy mają spore doświadczenie w używaniu Open Source w administracji państwowej, więc niewykluczone, że archiwa też mają w jakiś sposób na tym oparte.

Offline Rafał Rufus Magryś

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

 Dzięki Minder za link - jednak program ImgWorks okazuje się nie mieć podstawowej funkcji tzn. dodawania znaku wodnego. Możemy go dopasowywać ale możemy też wykorzystać siłę wiedzy Piotra i mieć nowy program.
Piotrze jeśli ten program (a właśnie jak go nazwać? :)...) będzie tak szybki jak beesoft commander to będzie genialnie! Czekam zatem na info co Ci będzie potrzebne (jaka pomoc) ze strony NAC i ze strony tworzącej się społeczności żeby zapewnić Ci komfort pracy.
Narzędzia (wiki, cvs etc.) będą uruchomione do 17 września na roboczej stronie NAC.

Pozdrawiam

Rafał

P.S. Znam projekty w NIemczech niestety tam OpenSource (jeśli chodzi o archiwa) jest w powijakach choć mają już coś na koncie nakładkę do Eclipse która ułatwia towrzenie plików w XML w DTD EAD (Encoded Archival Description)
P.S. Czekam na propozycje nazwy ;)...
Rafał "Rufus" Magryś
...patience is a virtue...

Offline piotrpsz

  • słuchacz(ka)
  • Wiadomości: 10
  • Płeć: Mężczyzna
    • beesoft.org
Piotrze jeśli ten program (a właśnie jak go nazwać? :)...) będzie tak szybki jak beesoft commander to będzie genialnie!

:) sam program bedzie szybki. Ale przetwarzanie obrazow juz chyba nie. Chociazby ze wzgledow na rozmiary konwertowanych plikow.

Cytuj
Czekam zatem na info co Ci będzie potrzebne (jaka pomoc) ze strony NAC i ze strony tworzącej się społeczności żeby zapewnić Ci komfort pracy.

Chcialbym znac dokladna specyfikacje co ten program ma robic. A konkretnie jakie opcje powinien moc wybrac/ustawic operator programu. Pozniej potrzebowal bym pewnie wsparcia ekspertow od przetwarzania obrazow.

Cytuj
P.S. Czekam na propozycje nazwy ;)...

IARC?

IA od (I)m(A)ge
ARC od (ARC)hiwum

Taki sobie zlepek liter.
Moze archiwisci maja jakas ekstra unikalna nazwe?
Pewnie tak.

pozdrawiam
Piotr

Offline dPeS

  • słuchacz(ka)
  • Wiadomości: 4
Powitać,

Witajcie,

Potrzeba: Program do masowej konwersji plików graficznych w wersji do instalacji lokalnej,

Wymóg: opensource na wszystkie platformy (winda, linux, mac os), optymalizacja w celu osiągnięcia największej prędkości przetwarzania plików,

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,

Pomysł na realizację: ...

Na początek pytanie - opis tego co trzeba zrobić zostanie udostępniony w poniedziałek ? nadal nie wiadomo ile danych będzie trzeba przetworzyć, gdzie te materiały się znajdują oraz jak wygląda ich zamienianie na postać cyfrową?

Jeśli zaś chodzi o powyższą funcjonalność to moim zdaniem nie potrzeba do tego żadnego programu. Jeśli użytą biblioteką ma być imagemagik to nikt nie jest w stanie użyć jej lepiej niż twórcy a więc zbiór narzędzi konsolowych (http://www.imagemagick.org/script/command-line-tools.php) spokojnie umożliwi zaproponowaną wyżej funkcjonalność. Znak wodny - i owszem - pierwszy link z google "imagemagick watermark" - http://www.selonen.org/arto/netbsd/watermarks.html. Owszem można się pokusić o stworzenie prostego GUI z kilkoma dużymi przyciskami które będą uruchamiały odpowiednie skrypty. Pytanie czy parametry ma podawać użytkownik czy też będzie to robiła pani Kasia przy kawie bez informacji umożliwiających ich wybór.

Moja propozycja : obecnie do zrobienia są dwa projekty, które mają taką samą funkcjonalność - jedyne co je różni to sposób wyświetlenia GUI (jeden standalone - desktop dla win32, lin, mac) drugi web. Warto więc pomyśleć o adapterze który z jednej strony będzie miał niskopoziomowe aplikacje convert, mogrify... do wykonywania operacji na plikach a z drugiej strony będzie udostępniał interfejs oczekiwany przez użytkownika np ,,weź te 20 plików ttf i zamień je na jpg''. Jeśli taki adapter zostanie napisany w przenośny sposób to będzie mógł działać zarówno na serwerze jak i standalone. Wystarczy później zrobić 2xGUI i koniec.

jeśli chodzi o wydajność : intuicja podpowiada mi, że dla dużych plików (o których mowa) wydajność tego typu operacji wykorzystując gotowe już narzędzia napisane przez twórców biblioteki będzie optymalna dla tej biblioteki. Nie sądzę, żeby można było prześcignąć autorów biblioteki.

dPeS

Offline minder

  • słuchacz(ka)
  • Wiadomości: 5
  • Płeć: Mężczyzna
dPeS, co do prześcigania autorów biblioteki, to nie do końca się zgodzę, bo choćby Ogg/Vorbis został znacznie ulepszony przez osoby obce. Nie wspominając już o hakerach C64, którzy robili rzeczy nieprzewidziane przez producentów ;)

Zgadzam się jednak całkowicie, że całą zabawę powinny realizować konsolowe skrypty z odpowiednią nakładką GUI - to jest "*NIX way" i właśnie tak zapewnia się wszechstronność. Python z linkami do odpowiedniej biblioteki graficznej (Qt/GTK) byłby chyba całkiem odpowiedni.

Stopień skomplikowania interfejsu użytkownika powinien być wielowarstwowy. Tryb najbanalniejszy powinien opierać się na podaniu plików na wejście, podaniu co ogólnie trzeba zrobić (np. konwertuj na png/djvu/coś innego/dodanie znaku wodnego/przeskalowanie) na zasadzie dodawania kolejnych etapów przekształcenia. W wersji bardziej skomplikowanie warto byłoby umożliwić jakieś operacje warunkowe (np. jeśli rozmiar przekracza ileśtam, to używamy takiego przekształcenia, a jeśli jest mniejszy, to innego; np. po prostu wrzucamy do różnych katalogów). Wymaga to pewnego poziomu abstrakcji w programie, ale w sumie nie jest to zbyt trudne do realizacji.

Offline dPeS

  • słuchacz(ka)
  • Wiadomości: 4
dPeS, co do prześcigania autorów biblioteki, to nie do końca się zgodzę, bo choćby Ogg/Vorbis został znacznie ulepszony przez osoby obce. Nie wspominając już o hakerach C64, którzy robili rzeczy nieprzewidziane przez producentów ;)

Mówiłem o wykorzystaniu biblioteki a nie jej ulepszaniu (co zdecydowanie nie jest tematem projektu). Rzecz w tym, że programy takie jak convert już dobrze wiedzą jakich procedur użyć i nie trzeba poznawać API biblioteki tylko po to żeby zrobić resize pliku.

dPeS

Offline Venomous

  • słuchacz(ka)
  • Wiadomości: 4
  • Płeć: Mężczyzna
    • http://www.nac.gov.pl
Panowie (i Panie?),
cudze chwalicie, swego nie znacie ;)
Mamy już program w jednym z AP, który seryjnie przetwarza pliki graficzne z wykorzystaniem biblioteki ImageMagick. Pracujemy na nim codziennie, zmieniając wybranym plikom format z tiff na jpeg (lub mniejszy tiff), zmniejszając ich rozdzielczość oraz dodając znaki wodne. Moduł ten działa poprawnie aczkolwiek wymaga optymalizacji. Problem w tym, że skorzystaliśmy tutaj z jedynego "sensownego" (jak odważył się stwierdzić Jan) rozwiązania i zleciliśmy napisanie tego soft'u ekipie programistów z zewnątrz. Ciągnie to za sobą pewne konsekwencje w postaci problemów z otwartym kodem oraz prawami autorskimi, ale sądzę, że jesteśmy w stanie przeciągnąć ekipę na naszą stronę (w tym konkretnym przypadku) - w końcu NAC to nie jakiś warzywniak na rogu - sława i chwała tym, którzy pomogą nam bezinteresownie.
Nie mówię tutaj o wdrożeniu tego oprogramowania na szerszą skalę, ale może nie potrzeba wyważać uprzednio otwartych już drzwi. Według mnie można skorzystać z pewnych dotychczasowych doświadczeń przy tworzeniu tego projektu. Postaram się niezwłocznie ruszyć tą sprawę i będę na bieżąco informował o postępach.

Pozdrawiam
Sebastian Zduńczyk (NAC)

Offline sirsilis

  • archiwa_2.5
  • st. kustosz(ka)
  • *
  • Wiadomości: 998
  • Płeć: Mężczyzna
hehe potwierdzam ze to fajny program  ;D

Mam pytanie czemu formatem wyjściowym jest tiff a nie np raw ???,
docelowy powinien być tylko jeden format - jpeg

z tego co widzę wszyscy myślą o tiffie (nie tylko AP) ale trzeba zadać pytanie czy naprawdę ten format jest dobry. Inna kwestia rozdzielczość - 600  czy 300 dpi Jest o o tyle ważne bo chodzi o pojemność na dyskach :) z doświadczenia wiem że 600 dpi jest zbędne i że 300 dpi oferuje podobną jakość plus mniejszy rozmiar

Offline Rafał Rufus Magryś

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

  A więc kolejno :)... : program powinien wymagać jak najmniejszej wiedzy ze strony usera i powinna to obsłużyć p. Kasia która będzie pić kawę podczas przetwarzania plików i Zenek vel "Speedy" guru pisania skryptów w pythonie. Zakładamy oczywiście, że wypadków eksteremalnych w obu przypadkach będzie mało, zatem musi to obsłużyć średniozaawansowany w generalnej obsłudze kompów user. Idealnym rozwiązaniem byłoby gdyby interfejs pozwalał w sposób "klikalny" na regulowanie wszystkich parametrów. Minder ma tutaj dużo racji proponując żeby móc wybrać rozmaite poziomy skomplikowania ustawień, aż do najwyższego w którym będzie możliwość wpisania komend.
Oczywiście, że w pierwszym etapie nie będziemy chcieli optymalizować etc. - ale dlaczego w drugim nie? Zrobimy wersję 1.0 a potem optymalizacja, optymalizacja! (czy bibliotek?) A może wersji 2.0 ten progs będzie mógł korzystać z Djvulibre i pluć djvu?
Ważne jest aby zrobić ten projekt dosyć szybko wersja stabilna winna się pojawić w ciągu jakichś 3-4 tygodni. Dlaczego tak? Dzisiaj byłem na spotkaniu w jednej z instytucji państwowych która też chce podjąć się zdigitalizowania całego swojego zasoby. Nie spojrzała w stronę środowiska open jak NAC i chce to zrobić w oparciu o firmy komercyjne (systemy, wiadomo sprzęt tak czy siak trzeba kupić). W tym momencie potrzebuje właśnie takiego oprogramowania do wsadowej konwersji plików - jeśli dostarczymy takiego oprogramowania zyskamy może jeszcze jedno wsparcie a być może niedługo i neofitów :)...

Venomous: Cieszę się, że system jest i działa tak jak powinien. Nie wiem czy firma zgodzi się na kompletną dostępność do kodu czyli najzwyczajniejsze open source. Tu chodzi o powszechne wdrożenie a nie o łaskę korzystania w NAC czy w dwóch, trzech "apach" (archiwach państwowych). W wypadku firmy nie robi ona tego beinteresownie ale wpisuje się pracowicie na listę referencyjną ;)... ale nie chcę wchodzić tu w dywagacje na temat tego co i jak. Zastanawiam się też nad jednym: dlaczego do tej pory firma ta nie udostępniała swoich narzędzi środowisku jako opensource? To nie znaczy, że należy w czambuł potępiać wszystko co zrobili -warto skorzystać z ich doświadczeń i proszę abyś fakycznie monitorował tę sprawę - szczerze powiedziawszy wiedzę masz tak dużą, że z palca jesteś w stanie wskazać pewne sprawy :)... Summa summarum nie chcemy wyważać otwartych drzwi ale nie chcemy też włazić oknem bo drzwi są za małe...

david: nie wiem co nie podoba Ci się w tiff - jest to standard zalecany przez środowisko archiwalne, co do raw nie mam nic przeciwko - a output powinien być w wybranym formacie a nie w jednym - nie zamykajmy sobie grona odbiorców. Co do rozdzielczości - tu nie można powiedzieć, że jest wystarczające: o ile dokument napisany na maszynie, czy nawet pisany ręcznie (ale tu już zależy jaki) zeskanowany w 300 dpi to i tak za dużo o tyle pieczęć, zdjęcie 600 dpi wymaga bardzo tej rozdzielczości.

piotrpsz: Piotrze jeśli potrzebujesz dokładnych "workflowsów" co ma progrsik robić (nawet flowcharty na ile potrafimy - choć nie wiem czy to tu będzie potrzebne) mówisz i masz - postaram się aktywizować w tej kwestii ludzi z pracowni z digitalizacji, choć i ja kiedyś w tam pracowałem to mogę opisać co i jak z tego co pamiętam ;)...
Co do nazwy może: NA(r)Cyz? ;) logo możnaby zrobić niezłe :)... a właśnie - JAKBY KTOŚ MÓGŁ ZROBIĆ LOGO DO TEGO PROGRSIKU BYŁOBY TO GENIALNE - oczywiście po wybraniu nazwy :)... Jak macie jakichś fajnych grafików znajomych to byłoby super.

Generalna uwaga: zróbmy może jeszcze jeden obrót dyskusji w związku z dosyć dużą pilnością sprawy (jak się okazało - ja myślałem, że to taki lajtowy projekcik i będziemy przy nim mogli dłubać i dłubać) i podzielimy sobie robotę żeby za te 3-4 tygodnie mieć coś stabilnego w ręku

Pozdrawiam

Rafał


P.S. dPes: Informacja dotycząca ilości danych funkcjonalności etc. będzie natomiast dotyczyła głównego projektu czyli budowy systemu zintegrowanego. Przepraszam, że jeszcze nie macie tych danych ale jak pisałem są w drodze ;)...
Rafał "Rufus" Magryś
...patience is a virtue...