-
1. Data: 2016-04-24 13:10:04
Temat: Mikroprocesory dekodowanie obrazków.
Od: "Bo(o)t manager" <b...@W...wp.pl>
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.
--
Pozdrawiam
Bo(o)t manager
-
2. Data: 2016-04-24 13:56:34
Temat: Re: Mikroprocesory dekodowanie obrazków.
Od: janusz_k <J...@o...pl>
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?
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.
--
Pozdr
Janusz_K
-
3. Data: 2016-04-24 14:14:31
Temat: Re: Mikroprocesory dekodowanie obrazków.
Od: Jarosław Sokołowski <j...@l...waw.pl>
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.
--
Jarek
-
4. Data: 2016-04-24 15:09:27
Temat: Re: Mikroprocesory dekodowanie obrazków.
Od: Sebastian Biały <h...@p...onet.pl>
On 2016-04-24 13:10, Bo(o)t manager wrote:
> Jeśli chciałbym wrzucić na kartę SD jakieś obrazki do
> wyświetlenia na LCD
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
> zdekodowania(chodzi mi o wydajność)? JPG
Najgorszy dla uC, wymaga ogromnej mocy obliczeniowej przy dekodowaniu.
>, PNG, a może tiff, czy coś
> innego?
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.
> 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.
Zajmuje bardzo dużo pamięci bo jest nieskompresowany.
-
5. Data: 2016-04-24 15:53:08
Temat: Re: Mikroprocesory dekodowanie obrazków.
Od: janusz_k <J...@o...pl>
W dniu 2016-04-24 o 14:14, 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ć?
--
Pozdr
Janusz_K
-
6. Data: 2016-04-24 20:29:53
Temat: Re: Mikroprocesory dekodowanie obrazków.
Od: "Bo(o)t manager" <b...@W...wp.pl>
On Sun, 24 Apr 2016 15:09:27 +0200, Sebastian Biały napisał/a:
[ciach]
> 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).
>
Raczej zdjęcia, jakaś grafika, 16bitów kodowanie najlepiej jak w lcd, a
tam jest 565 z tego co wiem.
> , to jaki format z kompresją będzie najłatwiejszy do
>> zdekodowania(chodzi mi o wydajność)? JPG
>
> Najgorszy dla uC, wymaga ogromnej mocy obliczeniowej przy dekodowaniu.
>
>>, PNG, a może tiff, czy coś
>> innego?
>
> 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.
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?
>>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.
>
> Zajmuje bardzo dużo pamięci bo jest nieskompresowany.
480 * 800 * 16 to 750KB, przyjmując że najmniejsza karta microSD jaką mam
to 1GB, to ponad 1000 zdjęć się zmieści.
--
Pozdrawiam
Bo(o)t manager
-
7. Data: 2016-04-24 20:34:45
Temat: Re: Mikroprocesory dekodowanie obrazków.
Od: Sebastian Biały <h...@p...onet.pl>
On 2016-04-24 20:29, Bo(o)t manager wrote:
> Raczej zdjęcia, jakaś grafika, 16bitów kodowanie najlepiej jak w lcd, a
> tam jest 565 z tego co wiem.
A więc albo masz masę wolnego flasha, albo jpg.
> 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.
imagemagick jest odpowiedzią jak to zrobić sensownie bez klikania i
obróbki wyniku, automatyzując to z make czy co tam masz.
> A może jest jakiś kontener na nieskompresowane zdjęcia pajniejszy od
> bitmapy?
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.
>> Zajmuje bardzo dużo pamięci bo jest nieskompresowany.
> 480 * 800 * 16 to 750KB, przyjmując że najmniejsza karta microSD jaką mam
> to 1GB, to ponad 1000 zdjęć się zmieści.
Czas czytania jest równiez istotny.
-
8. Data: 2016-04-24 23:27:07
Temat: Re: Mikroprocesory dekodowanie obrazków.
Od: Marek <f...@f...com>
On Sun, 24 Apr 2016 13:10:04 +0200, "Bo(o)t manager"
<b...@W...wp.pl> wrote:
> 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.
nie trzeba w gimpie, wystarczy imagmagic"owy convert input.jpg
output.xpm
--
Marek
-
9. Data: 2016-04-25 07:59:20
Temat: Re: Mikroprocesory dekodowanie obrazków.
Od: ww <w...@o...pl>
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.
>
>
Mi najszybciej udało się uruchomić to:
http://elm-chan.org/fsw/tjpgd/00index.html
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.
-
10. Data: 2016-04-25 10:29:45
Temat: Re: Mikroprocesory dekodowanie obrazków.
Od: "Andrzej W." <a...@w...pl>
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?
Wiem, że nie o to pytasz, ale może rozwiązać problem od drugiej strony?
LCD z kontrolerem z rodziny FT8xx ?
Np.:
http://elty.pl/pl/p/Wyswietlacz-LCD-5-480x272-z-pane
lem-dotykowym-sterowanianie-SPI,-kontoler-FT800-/119
6
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.
--
AWa.