Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

STM32F4 i mocna kompresja zdjęcia do JPG

09 Paź 2015 18:21 1059 10
  • Poziom 19  
    Witam.

    W swoim urządzeniu stosuję układ STM32F429. Układ robi zdjęcia za pomocą kamery, która wyrzuca obraz w formacje RGB565 (format BMP). Problem jest taki, że zdjęcie np. 640 * 480 zajmuje 640 * 480 * 3 = 921600B, co jest bardzo dużą liczbą, bowiem fotografię zamierzam przesłać przez RS232 do komputera... Zastanawiam się więc nad kompresją, np. JPEG. Czy dałoby się w prosty sposób przeprowadzić programowo taką kompresję? Są jakieś może dostosowane do STM32 biblioteki, kompresujące do JPG? A może są lepsze systemy niż JPG i można użyć innego konwertera, aby zakodować obraz i wysłać do PC tudzież dekodera, aby zdekodować obraz w PC i wyświetlić?
  • Pomocny post
    Moderator Mikrokontrolery Projektowanie
    Są gotowe biblioteki kompresji/dekompresji - poszukaj w Internecie. Ponieważ to kod w C jest generyczny i odpalisz go bez problemu na każdej platformie. Swoją drogą jeśli używasz tak wypasionego procka, to dlaczego nie połączysz go z PC za pomocą USB?
  • Poziom 19  
    tmf napisał:
    dlaczego nie połączysz go z PC za pomocą USB


    Niestety, ale USB wykorzystuję w innym celu.

    Co do kodera - znalazłem coś takiego w internecie:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    ze strony http://www.stm32.eu/node/351

    Mam tylko problem z prawidłową konfiguracją biblioteki, aby korzystała z zewnętrznej pamięci SRAM, którą mam już podłączoną. Ponadto nie za bardzo wiem, jak zmodyfikować:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Kod: c
    Zaloguj się, aby zobaczyć kod
  • Pomocny post
    Moderator Mikrokontrolery Projektowanie
    bipolunipol napisał:
    tmf napisał:
    dlaczego nie połączysz go z PC za pomocą USB


    Niestety, ale USB wykorzystuję w innym celu.


    Ale zdajesz sobie sprawę z tego, że istnieje coś takiego jak złożone urządzenie USB, tzn. takie, które przekazuje kilka deskryptorów USB. W efekcie możesz na tym samym interfejsie mieć to co masz + ileśtam np. wirtualnych RS232, czy mass storage, czy co tam wymyślisz...
  • Poziom 19  
    tmf napisał:
    Ale zdajesz sobie sprawę z tego, że istnieje coś takiego jak złożone urządzenie USB, tzn. takie, które przekazuje kilka deskryptorów USB. W efekcie możesz na tym samym interfejsie mieć to co masz + ileśtam np. wirtualnych RS232, czy mass storage, czy co tam wymyślisz...


    Dziękuję za informację. Sprawdziłem transfery i okazuje się, że nawet przy USB (Full Speed) musiałbym kompresować zdjęcia, bo czas ich wysyłania byłby za duży...
  • Moderator Mikrokontrolery Projektowanie
    bipolunipol napisał:
    tmf napisał:
    Ale zdajesz sobie sprawę z tego, że istnieje coś takiego jak złożone urządzenie USB, tzn. takie, które przekazuje kilka deskryptorów USB. W efekcie możesz na tym samym interfejsie mieć to co masz + ileśtam np. wirtualnych RS232, czy mass storage, czy co tam wymyślisz...


    Dziękuję za informację. Sprawdziłem transfery i okazuje się, że nawet przy USB (Full Speed) musiałbym kompresować zdjęcia, bo czas ich wysyłania byłby za duży...


    Moja propozycja była dodatkiem do kompresji. Ale coś mi nie pasuje - klasyczny RS232 wyciągnie 115200 bps, USB-full speed da ci 12 Mbps (teoretycznie), czyli 100x więcej, czyli więcej niż RS232 + kompresja JPEG.
  • Poziom 19  
    tmf napisał:
    Moja propozycja była dodatkiem do kompresji. Ale coś mi nie pasuje - klasyczny RS232 wyciągnie 115200 bps, USB-full speed da ci 12 Mbps (teoretycznie), czyli 100x więcej, czyli więcej niż RS232 + kompresja JPEG.


    Prawda, lecz w przyszłości zastosuję jeszcze większe rozdzielczości, co spowoduje spadek transferu... Np. zdjęcie 640 * 480 ma rozmiar ok. 1MB. Załóżmy, że będę korzystał z USB. Czyli wychodzi 1,5 zdjęcia na sekundę przy Full Speed, co jest trochę za małą wartością. Chciałbym w przyszłości wysyłać minimum 4 klatki na sekundę, co wymaga zastosowania kompresji ...
  • Poziom 19  
    Używany uP ma 225DMIPS i jest taktowany z f = 180MHz, więc nie powinno byc problemu z czasem kompresji.
  • Poziom 35  
    Nie był bym taki pewny. Ostatnio był podobny temat lecz o dekompresji i trwało to ok 1 sekundy. Nie pamiętam rozmiarów rysunku i częstotliwości uP.
  • Poziom 19  
    Sprawdziłem bibliotekę do JPEG, o której pisałem w pierwszym poście:

    Kod: c
    Zaloguj się, aby zobaczyć kod



    Zastanawia mnie, co mam zrobić z:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    - o jaki bufor 16 linii obrazu chodzi