Mikroprocesory dekodowanie obrazków.

Cześć! Jeśli chciałbym wrzucić na kartę SD jakieś obrazki do wyświetlenia na LCD, to jaki format z kompresją będzie najłatwiejszy do zdekodowania(chodzi mi o wydajność)? JPG, PNG, a może tiff, czy coś innego? Z bitmapą to chyba prosto, GIMP znów pozwala zapisać obrazki do plików .c lub .h, ale to znów dużo roboty jest bo trzeba by najpierw plik obrobić w GIMP'ie. I jak zwykle :-) - Z góry dzięki za pomocne odpowiedzi.

Reply to
Bo(o)t manager
Loading thread data ...

W dniu 2016-04-24 o 13:10, Bo(o)t manager pisze:

Jpg na pewno nie bo tam są transformaty kosinusowe, w png chyba też, tiff to chyba skompresowany BMP, więc zostaje Ci BMP lub tiff.

Reply to
janusz_k

Pan janusz_k napisał:

PNG ma kompresje bezstratną (w przeciwieństwie do JPG). Jest dobrze udokumentowany i ma dobrze zrobione biblioteki. To chyba najczęściej używany format w takich zastosowaniach.

Reply to
invalid unparseable

Więc określ ile mają bitow na kolor bo od tego wszystko zależy. W drugiej kolejności określ co na tych obrazkach jest aby ocenić czy RLE wystarczy (zdjęcia czy rysunki techniczne).

, to jaki format z kompresją będzie najłatwiejszy do

Najgorszy dla uC, wymaga ogromnej mocy obliczeniowej przy dekodowaniu.

Rozglądaj się za kompresjami opartymi o RLE, niekoniecznie ma to związek z jakimkolwiek znanym formatem (acz Amiga IFF się załapie). Ogólnie nie chcesz raczej formatu. Chcesz gołe dane.

Zajmuje bardzo dużo pamięci bo jest nieskompresowany.

Reply to
Sebastian Biały

W dniu 2016-04-24 o 14:14, Jarosław Sokołowski pisze:

Ok nie wiedziałem, czy są bibloteki PNG na małe procki czy trzeba samemu pisać?

Reply to
janusz_k

On Sun, 24 Apr 2016 15:09:27 +0200, Sebastian Biały napisał/a:

[ciach]

Raczej zdjęcia, jakaś grafika, 16bitów kodowanie najlepiej jak w lcd, a tam jest 565 z tego co wiem.

Cały pic polega na tym, by nie robić dziwnych obróbek tych plików z GIMP'a Trzeba tam powycinać różne znaki, pozamieniać np slash'e na przecinki itd.

A może jest jakiś kontener na nieskompresowane zdjęcia pajniejszy od bitmapy?

480 * 800 * 16 to 750KB, przyjmując że najmniejsza karta microSD jaką mam to 1GB, to ponad 1000 zdjęć się zmieści.
Reply to
Bo(o)t manager

A więc albo masz masę wolnego flasha, albo jpg.

imagemagick jest odpowiedzią jak to zrobić sensownie bez klikania i obróbki wyniku, automatyzując to z make czy co tam masz.

Bitmapa jesto dośc fajna pod warunkiem że nie trafisz na kolejną zmiane formatu BM. IMHO jedyna odpowiedzią jest konwersja na raw (jesli masz flash) lub jpg jesli nie masz flasha ale masz cpu.

Czas czytania jest równiez istotny.

Reply to
Sebastian Biały

nie trzeba w gimpie, wystarczy imagmagic"owy convert input.jpg output.xpm

Reply to
Marek

W dniu 2016-04-24 o 13:10, Bo(o)t manager pisze:

Mi najszybciej udało się uruchomić to:

formatting link
Szybkie to nie jest (na moim stm32f103) ale czasami i tak szybciej jest przesłać mały plik i zdekodować niż przesłać duży.

Reply to
ww

W dniu 2016-04-24 o 13:10, Bo(o)t manager pisze:

Wiem, że nie o to pytasz, ale może rozwiązać problem od drugiej strony? LCD z kontrolerem z rodziny FT8xx ? Np.:

formatting link
Wysyłasz po prostu JPEGa po SPI mówisz gdzie go ma pokazać i po kłopocie. Poza tym cała masa innych przydatnych funkcji pozwalających zrobić ładne GUI na 5" nawet i na 8051.

Reply to
Andrzej W.

Pan janusz_k napisał:

Nie wiem co rozumiemy przez "małe procki". Ale zdaje się, że widziałem pliki PNG przy projektach rzeczy obywających się bez systemu opercyjnego. Nie sądzę, by za każdym razem obsługę pisano od zera.

Reply to
invalid unparseable

Użytkownik "Bo(o)t manager" napisał w wiadomości

Ale jakie obrazki ? JPG sie nadaje do fotek z aparatu, za to np nie nadaje do rysunkow technicznych.

Tak ogolnie:

-BMP - duze, bo bez kompresji, ale za to proste.

-JPG - skomplikowane w odtwarzaniu, ale swietne do naturalnych widokow. Kompresja skompresowana i stratna.

-GIF - niezla alternatywa, kompresja zdaje sie dosc latwa, patent chyba juz dawno wygasl, ilosc kolorow ograniczona, no i przestarzaly jest.

-TIFF - smietnik, w ktorym jest wszystko. Nikt juz chyba nie potrafi powiedziec ile mozliwych formatow moze byc w srodku. Wiec zawsze sie moze okazac, ze obrazek niekompatybilny jest z tym co zaprogramowales.

-PNG ... troche jak TIFF - tez moze zawierac kilka formatow. Ale bardziej uporzadkowany. A ze kilka formatow, to tak naprawde kilka roznych funkcji do dekompresji. Za to nadaje sie dla roznych rodzajow obrazow.

Albo bedziesz obslugiwal wszystkie/wiele formatow, albo przerobka Cie nie minie ...

J.

Reply to
J.F.

W dniu 2016-04-25 o 10:45, Jarosław Sokołowski pisze:

Miałem na mysli 8-bitowce, szczególnie avr-y.

Reply to
janusz_k

Najprostsze są PBM i PGM oraz PPM. Pierwszy dla obrazków kolorowych, drugi dla skali szarości, trzeci dla czarno-białych. Mają one warianty binarne i tekstowe. Nie używają kompresji. Poszukaj w Google. Z innych formatów zrobisz je np. programem IrfanView.

Wada: duże pliki. Bo nie ma kompresji.

Reply to
slawek

Trochę zapomniany PCX, używający RLE, dekompresuje się niesamowicie łatwo i bez problemu 8-bitowiec sobie z tym poradzi. Tyle że obsługuje tylko

256 kolorów (+ paletę) :( No i nadaje się do kompresji tylko obrazków, przy zdjęciach RLE nie ma zastosowania.
Reply to
Adam Wysocki

Jak zdjęcia, to zapomnij o PCX i innych opartych na RLE, bo mogą wyjść większe niż adekwatny BMP.

Reply to
Adam Wysocki

A może PPM? To bardzo prosty format - tekstowy nagłówek i zaraz po nim binarne dane, są zdaje się trzy odmiany (1-bitowa, 8-bitowa i 24-bitowa) - PBM, PNM, PPM (nie pamiętam która jest która, ogólnie google: NetPBM).

Reply to
Adam Wysocki

W dniu 2016-04-24 o 13:10, Bo(o)t manager pisze:

PNG ze względu na kompresję i przezroczystość świetnie się nadaje w przypadku prostego gui czyli przyciski, tło, itp... Wszędzie tam gdzie jest dużo sąsiednich pikseli o tej samej wartości. Do zdjęć jak najbardziej JPG. Na AVR32 66MHz wczytanie, dekodowanie jpg'a 640x480 i wyplucie na ekran zajmowało mi OIDP około 300ms. Co ciekawe ten sam obrazek w PNG dekodował się dłużej, ale na to też miał wpływ kilkukrotnie większy rozmiar.

Reply to
Robert Zemła

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.