Pan janusz_k napisał:

>>>> 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?
>>> 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.
>>
>> 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.
>
> Ok nie wiedziałem, czy są bibloteki PNG na małe procki czy trzeba samemu
> pisać?

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.

--
Jarek

do góry

Użytkownik "Bo(o)t manager" napisał w wiadomości
>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?

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.

>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.

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

J.

do góry

W dniu 2016-04-25 o 10:45, Jarosław Sokołowski pisze:
> Pan janusz_k napisał:
>
>>>>> 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?
>>>> 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.
>>>
>>> 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.
>>
>> Ok nie wiedziałem, czy są bibloteki PNG na małe procki czy trzeba samemu
>> pisać?
>
> 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.
>
Miałem na mysli 8-bitowce, szczególnie avr-y.

--
Pozdr

Janusz_K

do góry

On Sun, 24 Apr 2016 13:10:04 +0200, "Bo(o)t manager"
<b...@W...wp.pl> wrote:
> zdekodowania(chodzi mi o wydajność)? JPG, PNG, a może tiff, czy coś
> innego?

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.

do góry

Sebastian Biały <h...@p...onet.pl> wrote:

> 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.

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.

--
http://www.chmurka.net/

do góry

"Bo(o)t manager" <b...@w...wp.pl> wrote:

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

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

--
http://www.chmurka.net/

do góry

Sebastian Biały <h...@p...onet.pl> wrote:

> 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.

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).

--
http://www.chmurka.net/

do góry

W dniu 2016-04-24 o 13:10, Bo(o)t manager pisze:
> 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.
>
>

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.

do góry