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.
Mikroprocesory dekodowanie obrazków.
Apr 24, 2016
17 Replies
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.
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.
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.
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ć?
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.
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.
nie trzeba w gimpie, wystarczy imagmagic"owy convert input.jpg output.xpm
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.
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.
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.
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.
W dniu 2016-04-25 o 10:45, Jarosław Sokołowski pisze:
Miałem na mysli 8-bitowce, szczególnie avr-y.
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.
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.
Jak zdjęcia, to zapomnij o PCX i innych opartych na RLE, bo mogą wyjść większe niż adekwatny BMP.
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).
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.
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required