Witam ponownie,
nie sądzę by firma udostępniła nam cały kod - to po pierwsze. Po drugie - firma nie wie o projekcie NAC Open Source - i chwilowo niech tak pozostanie. Oczywistym jest, że firma wchodząc w taki projekt chciałaby chociaż jakiejś reklamy - w tym przypadku niedopuszczalne. Moim zdaniem można wynegocjować udostępnienie nam mechanizmów dotyczących ImageMagick, ponieważ cała reszta to zwykła nakładka do przeszukiwania i przeglądania bazy danych, a to możemy napisać sami. Tym bardziej, że chcemy aby aplikacja działała nie tylko pod windą. Jeśli chodzi o samą bazę (pola, typy, klucze, relacje), to pełną specyfikację mamy i jest ona dostępna od ręki - można wykorzystać pewne elementy jako pomoc przy tworzeniu systemu. Mamy do tego prawo, ponieważ sami to pisaliśmy.
Druga sprawa - TIFF jest standardem i nie powinniśmy tracić czasu na rozmyślanie czy to dobrze, czy źle. Większość jest zadowolona i lepiej przy tym zostańmy. Późniejsza migracja do innych standardów to zupełnie odrębna sprawa, a kiedy projekt urośnie w siłę, to nawet się nie obejrzymy jak takie funkcjonalności zaczną się pojawiać. Nie mówię tutaj o migracji z TIFF do RAW, bo to absurd, a sam RAW nie jest idealny. Został stworzony z myślą o przenoszeniu obrazów między aplikacjami i różnymi
platformami komputerowymi. Dane z obrazów RAW modyfikowane są (barwy są interpolowane) zgodnie z wybraną wcześniej matrycą kolorów, trybem balansu bieli oraz parametrami przetwarzania (modyfikacje te są bezstratne), po czym możemy je zapisać w dowolnym formacie. Problem w tym, że stworzenie poprawnego output'u dla tego formatu zależy w głównej mierze od zdefiniowanych ustawień. Do obsługi RAW w projekcie potrzebowalibyśmy solidnego kombajnu, a nawet wśród komercyjnych produktów nie jest jeszcze tak do końca kolorowo.
Idąc dalej za rozważaniami - 600 dpi być musi i wg mnie nie można tutaj pójść na żadne ustępstwa - przykład podany przez Rafała idealnie wskazuje na konieczność korzystania z takiej rozdzielczości. Ponadto informacja nadmiarowa nigdy nie jest wadą (chyba, że chodzi o cash). I tutaj przytoczę słynne powiedzonko: "Lepiej kijek obcienkować niż go potem pogrubasić". Po dziś dzień spotykam się z sytuacjami, gdy operator skanera, czy archiwista skanuje przez pomyłkę obiekt w 300 dpi, a potem zorientowawszy się w popełnieniu błędu interpoluje tą rozdzielczość w Photoshop'ie myśląc, że wyjdzie na to samo - niedopuszczalne. Głównym problemem jest rotacja kadr i brak szkoleń, ale to już off-topic.
