Hej!

Może wpierw od założeń zaczne:
ZAŁOŻENIA:
- kompresja stratna, bez możliwosci zmiany poziomu kompresji, zysk około 75%, jakość - nie wiem (jestem w trakcie pisania takiego próbnego kodera/dekodera żeby przekonać się jak to wygląda w praktyce)
ZASTOSOWANIE:
- dla grafiki w 15 trybie (160x192x4kolory), w odcieniach kolorow kolejno stopniowanych (ale tez mam pewien pomysl jak poradzic sobie z roznymi kolorami, aby wynik był zadawalajacy, ale podkreślam nie wiem jak to wyjdzie w praktyce.
KODOWANIE OBRAZU:
- Obraz dzielimy na wirtualne, nazwijmy to obszary 16 pixelowe (4x4) czyli w ten sposob uzyskujemy pole skladające sie z 40x48 obszary.
- każdy pojedyńczy obszar zapiszemy tylko na 1 bajcie !
- pojedynczy obszar dzielimy wirtualnie pionowo i poziomo na pół. usyskujac 4 mikro obszary 2x2 pixle
      AB AB
      CD CD

      AB AB
      CD CD
- Badamy kolejno każdy mikro obszar pod względem wartości kolorów znajdujących się w tym obszarze i wykonujemy działanie
INT((A+B+C+D)/4) -> uzyskana wartość bedzie z przedziału 0-4 (całkowita). Zapisujemy wiec ja na 2 bitach
00 dla 0
01 dla 1
10 dla 2
11 dla 3
- tak zakodowana wartosc sredniego koloru dla wszystkich mikroobszarów umieszczamy obok siebie w 1 bajcie (1 obszar=4 mikro obszary) np: 01 11 00 10
ODKODOWYWANIE:
- W pamieci tworzymy tablice 255 klocków, które mają rozmiar 4x4 pixle (tyle co jeden obszar). Kazdy klocek wiec składa sie z 4 kolejnych bajtów reprezentujacych wyglad graficzny jednego obszaru (255 klocków, dlatego że tyle jest wszystkich kombinacji 4^4). W sumie tablica zajmie 1024 bajty - 1 kilo
- odczytujac jeden bajt obrazu, skaczemy na poczatek tablicy klockow, odczytana wartosc bajtowa (0-255) z obrazu * 4, skaczemy pod adres poczatek_tablicy+(odczytany_bajt*4), odczytujemy z niego 4 kolejne bajty i kopiujemy odpowiednio na pamiec obrazu (np: $a150,A  $a150+40,B $a150+80,C $a150+120,D) czyli poszczególne bajty pod siebie...
- w ten sposob odczytujemy wszystkie 40X48 obszarów...
PODSUMOWANIE:
  tablica klockow =1024 bajty
  dane obrazu  =1920 bajty
  ------------------------------
suma: 2944 bajty dla całego obrazu w 15 grafice + pamiec dla procedurki dekodujacej, ale nastepny obraz to dodatkowo tylko 1920 bajtow...
TWORZENIE TABLICY KLOCKOW
- Tworzymy 255 kombinacyjnych klocków o rozdzielczosci 4x4
- znaczace kolory umieszczamy w rogach kwadratu wg ustalonej kolejnosci np.
  1x x2
  xx xx

  xx xx
  3x x4
- pixle oznaczone X interpolujemy do czterech baz kolorów na rogach.
- obszar zapisujemy na 4 bajtach
   1 bajt
   2 bajt
   3 bajt
   4 bajt
===============================================
ps1. Panowie napiszcie co sądzicie o moim pomyśle ?
ps2. Jakby fajnie wyszło to może ktoś napisze jakiś sofcik suportujący ten wynalazek
ps3. Moze ktoś ma lepszy pomysl ??
ps4. Pomyslałem sobie że jak fajnie bedzię to wyglądać to może sie pokusić na konwesje LARRY'ego na Atarke... z grzyba... grafika cało ekranowa chociaż skompresowana :) ale to już bym potrzebował mocnego wsparcia od kogoś od was
===============================================

DELY - Moze stworzyć rubryke a'la RFC dla malucha :) może coś ciekawego się wykroi :)

pozdrawiam...

jakby co to do mnie zajac4@wp.pl
-------------------------------------------------------------------------------------

Zajec/sword ;)

2

wiec tak:
1. rozdzielczosc: 40x48 jest lame, tylko 40x59 :)
2. wytlumacz mi moze czy po dekodowaniu bedzie JAKAKOLWIEK
roznica miedzy dwoba takimi kombinacjami 2x2 pixle
AB     
CD
i
DC
BA
?
z tego co czytam Twoj pomysl wynika ze zadnej nie bedzie, co znaczy, ze Twoj pomysl tak naprawde sprowadza sie do tego, ze zmniejszamy rozdzielczosc obrazka 2x w kazdym wymiarze i potem interpolujemy efekt.
3. ogolnie uwazam ze duzo lepsza bylaby metoda patrzaca jakie dane sa kompresowane... ofkorz mozna laczyc jedna i druga...

takze, sorry, ale mi sie to nie podoba.
ale pomysl RFC na malucha bylby ofkorz kewl :)
/eru

: 404. Stopka not found

3

1. Zadna rozdzielczosc 40x48, tylko 160x192!!!, a 40x48 byłoby obszarów interpolacyjnych!!! , niezrozumieliśmy sie :)

2.Jeśli rozpatrujemy tylko mikro obszar 2x2 to faktycznie różnica żadna :(
ale nie bedzie efektu powiekszonego pixla z 1x1 na 2x2, ponieważ
wartości w mikro obszarze oprocz tego znaczacego pixla bedzie interpolowana do znaczacych pixli w pozostałych 3 mikrobszarach sasiednich...

ps. Podkreślam że nie wiem jak to wyjdzie w praktyce, ale może się okazać że całkiem to nieźle bedzie wyglądać.

ps2. Moje kolejne udoskonalenie polega na wprowadzeniu piatego pixla znaczacego, który by odbywał znacząca role w interpolacji, mianowicie pixel srodkowy, którego wartosc koloru by byla srednia arytmetyczna kolorow pozostałych pixli znaczacych z 4 mikro obszarów.

ps3. Oczywiscie masz prawo ze ci sie moj pomysl nie podoba, szkoda :(

ps4. Ale dobrze że pomysł RFC dla malucha przypadł ci do gustu, co na to pozostali ??? no i DELY ???

Zajec/sword ;)

4

fajnie, fajnie ale chcialbym to zobaczyc na zywo.
algorytm jest, czas wiec na procedurke

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

5

1. kiedy mialem 40x59  to ofkorz mialem na mysli obszarki a nie rozdzielczosc... zastanawiam sie czemu wiekszosc atarowcow zapomina ze 320x192 jak nam zaproponowali autorzy trybow BASICa nie jest bynajmniej maximum... teoretycznie 384x239, 384 sie nie da wyciagnac, moze z 350-360, ale 239 jak najbardziej... zobaczycie niedlugo zreszta, co ja bede mowil :)

2. no ja przeciez nie mowilem ze bedzie efekt powiekszonego pixela... ale wlasciwie Ty nie proponujesz KOMPRESJI tylko metode powiekszania obrazka z blurem:)... i co z tego ze nie bedzie efektu pixla 2x2... to ja moge takie samo cos zrobic dla obszarkow 16x16 - idea ta sama, efekt - zgadnij  :rolleyes:

3. co do porownywania tego do JPEG, to chyba nie doceniasz JPEG :D (swoja droga, pare dni temu ktos oglosil ze ma na to patent i ISO zastanawia sie nad wycofaniem JPEG jako standardu)

4. pixel srodkowy znowu nic nie pomoze - problemem w Twoim schemacie jest to ze kazda permutacja kolorow w zrodlowym obszarze 2x2 daje ten sam efekt w wyniku... np siateczka czarne-biale-czarne-biale i tlo szare dadza w wyniku tlo szare....

5. interpolacja ktora proponujesz da dosyc ciekawy efekt, mianowicie w srodku kwadracikow 4x4 beda plynne przejscia kolorow dzieki interpolacji, natomiast na granicach kwadracikow a juz zwlaszcza na rogach beda ostre kontrasty... Poza tym interpolacja w trybie 15tym... eh... kiepa.

takze, fajnie ze myslisz nad metoda kompresji, ale najpierw moze rozejrzyj sie co JUZ jest dostepne :)
peace and no hard feelings, ofcourse :o
/eru

: 404. Stopka not found

6

(swoja droga, pare dni temu ktos oglosil ze ma na to patent i ISO zastanawia sie nad wycofaniem JPEG jako standardu)

Powaznie?? A dopiero w JDK 1.4 dodali koder/dekoder JPGa. Do GIFa jest tylko dekoder, ze wzgledu na glupi patent sprzed kilkunastu lat (na szczescie chyba wygasa).

Jakby znac dobrego prawnika, mozna sie niezle dorobic, opatentowac jakis popularny format. Nie da sie? W USA jest patent na kompresje, ktora daje gwarantowany zysk. Np. dwa bity kompresuje do jednego. :D

https://www.youtube.com/watch?v=jofNR_WkoCE

7

oj narobilo sie tych patentow...
DiviX 5.0 oraz Mpg (caly!) - za komercyje zastosowanie tych formatow  trzeba bulic, i to nie malo. Np za Mpg 3% zysku ale nie mniej niz 3000$ rocznie.

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org