Tak się zastanawiałem nad możliwością umieszczania krótkich informacji o pracy graficznej w plikach graficznych, co by było korzystne przy przedstawianiu prac na różnego rodzaju compo. Do tej pory na większości party jest wymagany plik z autorem (autorami) pracy itp. A jakby tak stworzyć uniwersalny nagłówek? Technicznie to jest to parę minut roboty, a według mnie - ułatwiłoby życie wielu organizatorom party. Co proponuję: 1. Stworzenie 40 bajtowego nagłówka do prac graficznych: xxx - trzy pierwsze bajty są wyróżnikami pliku (np. GR8, GR9, TIP, CIN) - w formie tekstu 10 kolejnych bajtów - info o autorze 17 kolejnych - pełen tytuł 10 pozostałych - dodatkowe info (na przykład rozdzielczość, ustawienia kolorów - kwestia ustaleń). 2. Dlaczego 40, a nie na przykład 100/200/1000? Dlatego, że taka ilość wydaje mi się rozsądna: praktycznie każdy autor się zmieści (po ksywce), jak i 17 znaków na tytuł powinien wystarczyć. Ustawiłbym taki nagłówek na sztywno, aby hipotetyczna przeglądarka miała łatwiejsze zadanie, a poza tym - po wczytaniu obrazka gdziekolwiek można by było pominąć pierwsze 40 bajtów (czy ile by się tam ustaliło) w celu wykorzystania takiej pracy. 3. Po co i na co? Aby w przyszłości można było bezwzględnie stwierdzić, kto taką pracę poczynił. Dodatkowo - przy wyświetlaniu na party widzę samą grafikę, ale po wciśnięciu ustalonego klawisza - wyświetla mi się info o pracy (jak to jest już często rozpowszechnione w utworach muzycznych z różnych parties). Co o tym sądzicie?
Ja uwazam to za dobry pomysl, ale to by trzeba przekonac organizatorow zlotow, a nie mnie :).
Mam tylko uwagi do implementacji: ad 1. mnie sie zdaje, ze jednak 40 bajtow to za malo. Proponuje 128 - bedzie zajmowac 1 sektor na dysku, ktory sie zmarnuje w sporej czesci, jezeli zajete bedzie tylko 40 bajtow. A po co az tyle?
ad 2. xxx na wyroznik formatu pliku to za malo. Proponuje 4 a moze i 5. Sa rozne odmiany danego formatu, wiec dodatkowe oznaczenie np. A, B, X sie przyda.
ad 3. 10 bajtow na info a autorze to za malo. Owszem, zmiesci sie Kaz czy Sikor, ale Sukkhor_Beneth juz nie. Powiedzmy, ze tak ze 32 bajty starcza.
Kolejne 32 bajty - pelny tytul. Owszem, grafika "Sen" sie zmiesci w 17 bajtach, ale juz "Kapitan Nemos mowi dobranoc", co staralem sie kiedys narysowac, juz nie.
Brakuje mi tez daty publikacji dziela. Moze to byc sam rok, ale powinna tez byc mozliwosc podania pelnej daty. Na to tez potrzeba kilku bajtow. Pozostale bajty bylyby do wykorzystania.
Ciekawy pomysł, ale moim zdaniem raczej się nie przyjmie :(
Co do pliku nagłówka. Jeśli 128 to dlaczego nie 256? Sektory na dyskietce DD są 256 bajtowe. A jeśli już, to bodajże 3 bajty w każdym sektorze są zajęte przez system plików. Do dyspozycji mamy 125 (w sektorze 128). Plik o długości 128 bajtów zajmie dwa sektory.
Ja bym proponował zrobić bardziej uniwerslany nagłówek, gdzie długość poszczególnych elementów mogłaby być dowolna. Działałoby to analogicznie do pliku dosowego. 1. xxxxx - jakiś tam nagłówek, czyli kilka charakterystycznych bajtów, aby wiadomo, że to ten nagłówek, a nie dane np. obrazka 2. dwa bajty - długość danych_nr_1 - za tymi bajtami dane_nr_1 (o długości wskazanej przez te dane) - to może być info o programie graficznym 3. dwa bajty - długość danych_nr_2 - za tym kolejne dane - np. tytuł . . . x. dwa bajty = 255,255 (lub ustalone inne) - koniec nagłówka x+1. - dane obrazka
generalnie miałoby to postać:
znacznik_nagłówka,długość_rekordu_1,rekord_1,długość_rekordu_2,rekord_2,długość_rekordu_3,rekord_3,....,znacznik_końca, dane obrazka
Oczywiście każdy z rekordów danych byłby narzucony przez specyfikację. I tak np. - pierwszy rekord, to info o typie grafiki, drugi rekord - tytuł, trzeci - autor, czwarty - grupa, piąty - inne, itd.
Kilka pierwszych rekordów musiałoby być obowiązkowych, a kolejne to już dowolnie (ilość nieograniczona). Jeśli ktoś z jakiś względów chciałby pominąć autora lub np. tytuł, to wystarczy wskazać w długości danych (rekordu) 0, czyli wstawić 0,0.
Taka konstrukcja nagłówka pozwoliłaby na umieszczanie dowolnej długości danych. Wymaga to oczywiście stworzenia generatora takich nagłówków, jak i umieszczenia w przeglądarkach graficznych procedury potrafiącej odczytać coś takiego (nic trudnego).
Moim zdaniem taki nagłówek będzie miał rację bytu jeśli powstanie uniwersalny program do odczytu wszelakiej maści obrazków na Atari. A takowego to chyba jeszcze nie ma...
w sumie to rozwiązanie larka jest dobre, nie da się ukryć, ale... jak w każdym przypadku ma swoje wady. Równie dobrze, można by machnąć XML, albo inną tego typu strukturę. To tak BTW. :D Po za tym. Są już pliki graficzne i "odtważarki" i co z nowymi i starymi plikami? Nowe się nie otworzą w starych? Można by plik z informacją walnąć na koniec pliku z grafiką. Problem w tym, że trzeba by przeszukiwać cały plik w celu pozyskania informacji. Plusem rozwiązania, full kompatybilność wsteczna :D Tak mi się wydaje przynajmniej.
Ciekawy pomysł, choć nienowy. Na Amigach od samego początku istniał standard zapisu dowolnych plików opracowany przez twórców systemu (oidp). Format IFF (Interchange File Format) - jego ideą była możliwość osadzania w plikach bloków dowolnych danych. Dzięki temu w pliku można było mieć dane graficzne, muzyczne, dane specyficzne dla różnych programów (np. właśnie informacje o autorach, czy jakiś komentarz), czy takie które logicznie w tym samym pliku powinny się znaleźć, bo są z nim związane. IFF pozwalał również na zapis hierarchicznych struktur danych (katalogi). Parser plików IFF musiał być za to tak skonstruowany, żeby pomijać bloki, które go nie interesują np. jeśli w pliku z grafiką rastrową ILBM mieliśmy przykładowe bloki BMHD (bitmap header), CMAP (color map), BODY (treść obrazu) i dodatkowo jeszcze jakiś tekst np. TEXT (strzelam - rodzaj bloku mógł być dowolny) zawierający kawałek jakiegoś tekstu, to viewer dla obrazków omijał blok TEXT, ale analizował pozostałe. Odwrotnie - edytor tekstów powinien przeanalizować tylko blok TEXT nie dotykając pozostałych. Może warto byłoby skorzystać z niezłego standardu, który zdążył okrzepnąć przez prawie 20 lat :) ? Zdaje się, że w którymś numerze Kebaba albo Magazynu Amiga był niezły opis IFF'a, z którego korzystałem przy eksporcie obrazków w GRAPH8.
@mono, zgadza się, pomysł stary jak świat. A przypuszczam, że bardziej by się nadawał do archiwizacji scenowych obrazków. @zilq - tak, stare przeglądarki tego nie odtworzą (przynajmniej jeśli się nie wyrzuci nagłówka). Ale z drugiej strony - chodzi o nowe prace, głównie prezentowane przy jakiś compo. Co więcej - można zrobić taką "mobilną" przeglądarkę - wczytuje ona nagłówek i po pewnych bajtach rozpoznaje format, po czym wczytuje cały obrazek lub odpowiednią "wtyczkę", jeśli w danej chwili nie ma biblioteki do obsługi tego typu grafiki (powstaje hipotetycznie nowy format grafiki - nie zmieniamy przeglądarki, tylko tworzymy nową "wtyczkę"). Oczywiście - takie sprecyzowanie tematu wymaga przemyśleń co i jak, ale myślę, że da się zrobić.
Tutaj ( ->link<- ) jest specyfikacja IFF - autorami są Electronic Arts, a nie Amiga Inc. jednak. Oidp nagłówki można było rejestrować w jakiejś organizacji (nie wiem czy ona jeszcze istnieje), tak więc jest jak do tej pory już pewna liczba standardowych rozwiązań. Trzeba byłoby po prostu zdefiniować pewną liczbę własnych nagłówków i zamiast rozpoznawać typ automagicznie, po prostu sprawdzić typ nagłówka z danymi. Przykładowo obrazki w TIP miałyby własny blok "TIP ", w CIN "CIN " lub coś w tym stylu. Format jest imho bardzo elastyczny. Nie mówię już o przechowywaniu thumbnails w samym pliku obrazka. Prawdę mówiąc zupełnie nie rozumiem dlaczego taki format nie przyjął się na piecach... A jak było na ST?
Edit: A tak w ogóle to wyżej ( ->link<- ) facet ma sporą kolekcję opisów formatów plików :) 2d i 3d oraz narzędzi (heh - przypadkiem trafiłem na ciekawą stronę :]; ileż to w życiu zależy od przypadku...).
1. Sikor: "tak, stare przeglądarki tego nie odtworzą (przynajmniej jeśli się nie wyrzuci nagłówka). Ale z drugiej strony - chodzi o nowe prace, głównie prezentowane przy jakiś compo."
I na to jest rozwiazanie. Wystarczy, ze bedzie to dodatkowy plik o tej samej nazwie, ale innym rozszerzeniu jak rysunek (np. obrazek ATARI.TIP to plik dodatkowy ATARI.INF). Przegladarka moze po prostu szukac plikow INF, a stamtad dowiadywac sie, co i jak - i ladowac wlasciwy plik z grafika z wszystkimi informacjami z pliku INF. Funkcjonalnosc takiego zewnetrznego pliku jest ogromna, bo mozna rzeczywiscie trzymac tam dane o wszytkich rodzajach danych - nie tylko grafiki, ale i muzyki czy programow. O ilez latwiej by bylo, gdyby mozna bylo w takim pliku informacyjnym przeczytac, czy dany program to jest Atari Basic, Turbo Basic czy Microsoft Basic.
A sa dwie podstawowe zalety tego rozwiazania. W ten sposob zachowujemy kompatybilnosc ze starymi przegladarkami (bo one czytaja tylko sam rysunek) oraz dajemy nowe mozliwosci wspolczesnej przegladarce.
2. Mono: " Prawdę mówiąc zupełnie nie rozumiem dlaczego taki format nie przyjął się na piecach... A jak było na ST?"
Na ST przyjal sie tylko jako format Deluxe Painta :), bo to byl program, ktory wyroznial sie na tle konkurencji innych programow graficznych. Potem oczywiscie niektore programy potrafily to odczytac, ale jakiegos wielkiego entuzjazmu IFF nie zauwazylem.
Mysle, ze przyczyna niepowodzenia IFF jest jego, mimo wszystko, niepraktycznosc. Poniewaz wlasnie jest uniwersalny to nigdy nie wiadomo, co tak naprawde zawiera dany plik... Pamietam, ze probowalem przeniesc z Amigi jakies obrazki czy animacje i strasznie mnie to wkurzalo, ze nigdy nie wiem, co tam jest w srodku. Bez programu, ktory przeanalizuje zawartosc (cudzego albo napisanego samemu) nic nie wiadomo. Na ST byl wtedy tylko DP, ktory zglaszal co najwyzej, ze format niepoprawny (i nie wiadomo dlaczego - bo za duzo kolorow? bo to animacja? bo to widzimisie?).
No i sam format nie jest banalnie prosty - trzeba bylo miec do niego opis, co w czasowach przedinternetowych nie bylo takie proste.
Ano format nie jest łatwy w analizie. Ale zauważcie, że jest to taki xml w postaci binarnej - rzecz łatwa w rozszerzaniu. Do xml dzisiaj mamy masę parserów, do iff trzeba byłoby to zrobić. Mnie osobiście ten format się bardzo podoba, bo jest prekursorem dzisiejszych rozwiązań (a kto wie, czy w końcu po chwilowej fascynacji tekstowym i nadmiarowym xml nie dotrzemy znowu do binarnego iff ale zaopatrzonego w narzędzia :D), ale nie zamierzam go forsować na siłę. Twój pomysł Kaz z dodatkowymi plikami ma swoją zaletę, bo zapewnia kompatybilność wstecz. Ma jednak wadę, bo z samym plikiem graficznym trzeba dystrybuować inne pliki dodatkowe, a to już mi się nie bardzo podoba :( Ten problem jest właśnie rozwiązany w IFF - wszystko co logicznie jest związane z plikiem graficznym znajduje się również w nim. Można to jednak rozwiązywać przez dostarczanie archiwum (IFF pełni właśnie również taką rolę). Mam za to wrażenie, że to że nie wiadomo co jest w jakim pliku, to nie jest wina IFF a specyfiki Amigi. Tam nie było czegoś takiego, jak rozszerzenie - tylko nazwa. Zauważ, że z biegiem czasu wypracowano pewną konwencję, w której rozszerzenie dodawano na początku pliku np. "mod.enigma". Na piecu za to, gdzie rozszerzenia są od czasów dosa pliki iff/ilbm z grafiką mają rozszerzenie .lbm :) więc nie ma żadnego problemu z rozpoznaniem.
@Ma jednak wadę, bo z samym plikiem graficznym trzeba dystrybuować inne pliki dodatkowe, a to już mi się nie bardzo podoba :(
Mozna zrobic tak, ze nie trzeba. W samym pliku informacyjnym mozna zawrzec informacje, czy plik wlasciwy jest osobno (dla zachowania pelnej kompatybilnosc) czy "wewnatrz". W tym drugim przypadku tracimy pelna kompatybilnosc, ale tylko dla najnowszych produkcji. Za to stare programy nie maja problemu z przeczytaniem starych plikow, a nowe programy - wszystkiego. To taki troche zgnily kompromis :).
Reasumujac - jak sie zrobi uniwersalna przegladarke do wszystkich formatow to mozna forsowac wlasny standard... :). Wtedy jest szansa, ze ktokolwiek zechce tez stosowac ten format. Tak jak bylo z SAP. Powstalo cos na ksztal uniwersalnego pliku muzycznego, format jest pecetowski, ale zdaje sie, ze powstaja jakies rozwiazania na Atari, ktore maja za zadanie czytac SAP (no, przynajmniej w pewnym zakresie).
@Kaz, @mono: tu się zgodzę z mono - jeden plik. Z biegiem czasu wszelkie pliki inf itp lubią się gubić. A tak mamy archiwizację w pliku. Oczywiście to tylko propozycja ;)
Jak Ci sie zgubi plik INF to najwyzej nie bedziesz mial pliku INF, a obrazek da sie odczytac. A jak Ci sie zgubi caly plik, w ktorym masz tez obrazek? ;)
A powazniej - uniwersalny format grafiki podobny do SAP bylby przydatny, moze nawet postulowany przez Mono IFF, ale to jest kwestia checi tworcow oprogramowania, a nie mojego gdybynia na forum :).
Kaz: i tak, i nie. Ile jest prac, o których niewiele wiadomo? Info w nich zawarte rozwiązało by pewne wątpliwości. Jak napisałem wcześniej - chodzi głównie o nowe prace, scenowe. Ale nieważne, w sumie nie znam się na tym... ;)
Masz racje. Pliki bez zadnych informacji, w szczegolnosci graficzne, to dla mnie zmora.
Tylko, ze to trzeba przekonac programistow/organizatorow party. Ja jestem przekonany, ze to dobry pomysl, niezaleznie od tego, jak to bedzie w szczegolach wygladac :)
Zajrzałem tutaj i mam pomysł: niech będzie to pojedyńczy plik typu archiwum lzh/lzip - tzn. nagłówek będzie pliku skompresowanego w kompresji 0% (brak kompresji), wewnątrz plik info i plik grafiki odrębne - dzięki temu i wilk syty i owca cała. Pomysł nienowy - w ten sposób kompresowane są pliki swf w samodzielnym projektorze saPlayer.exe - jeden duży exe to dll-ka odtwarzacza i właściwy swf modułu.
@MaW: To jest chyba najlepszy kompromis. Archiwum .lzh/.zip można zrobić na dowolnym komputerze. Taki "format" zresztą byłby bardzo elastyczny, a należałoby tylko opisać jego strukturę, czyli co ma się znaleźć w archiwum. W technologiach związanych z javą takim "formatem" jest .jar (Java Archive) i pochodne .war, .ear, itp. W środku zawsze znajduje się plik META-INF/MANIFEST.MF zawierający różne informacje zapisane tekstem w postaci kluczy: klucz: wartość<eol> np. Main-Class: onebit.chrdraw.CHRDraw oznacza, że klasą zawierającą program do uruchomienia w archiwum jest onebit.chrdraw.CHRDraw. U nas można by zdefiniować odpowiednie klucze odpowiadające za format obrazka, jego położenie w archiwum, program wyświetlający itd.
