I del 2 av artikelserien om kamerabaserad systemkonstruktion tittar Aaron Behman från Xilinx och Adam Taylor, CEng FIET, närmare på bildbehandlingen.

Ett växande antal smarta system i bilbranschen och inom medicinska, industriella och vetenskapliga områden är beroende av högkvalitativa bilder och högkvalitativ behandling, ofta med hög hastighet och i fullfärg. Föregående artikel i den här serien tog upp urvalskriterier för bildsensorer. I den här artikeln går vi igenom de största utmaningarna och de viktigaste besluten vid utvecklingen av bildbehandlingssystemet.

Det planerade lanseringsdatumet innebär ofta hård press som kan avgöra vilka delar av systemet som ska utvecklas internt och representera värdeskapande aktivitet, och vilka utvecklingsblock som ska köpas in som standardlösningar (COTS) eller från underleverantörer. Fokus på värdeskapande aktiviteter och utnyttjande av IP-moduler på maskinvaru-, programvaru- och FPGA-nivå är viktiga faktorer för att hinna till lanseringsdatumet.

Vad gäller tekniska utmaningar utvecklas inbäddade kamerasystem vanligtvis för tillämpningar där storlek, vikt, kraft och kostnad – ofta kallade SWaP-C – är drivande faktorer. Ett sätt att förbättra SWaP-C är genom högre systemintegrering, särskilt i processorsystemet.

Bildbehandlingspipeline och -algoritmer
Nästan alla inbäddade kamerasystem innehåller en bildbehandlingspipeline som samverkar med den valda sensorn och utför åtgärderna som krävs för att skapa en bild som är lämplig för ytterligare behandling eller överföring via ett nätverk. En grundläggande bildbehandlingspipeline kan innehålla delarna i fig 1.

Fig 1. Bildbehandlingspipeline (klicka för större bild)

Inom den här bildbehandlingspipelinen tillämpas olika algoritmer på mottagna bilder beroende på programmet som genomförs. Det finns ett antal vanliga algoritmer för processer som gör bilden skarpare, förbättrar kontrasten eller upptäcker särdrag, objekt eller rörelser.

Dessa algoritmer ska tas fram inom en struktur som möjliggör kortast möjliga tid till marknad och främjar återanvändning av beprövad IP samtidigt som icke-återkommande och återkommande tekniska kostnader minskar. Ett antal ramverk kan vara lämpliga.

* OpenVX – program med öppen källkod för utveckling av bildbehandlingsprogram
* OpenCV – öppen källkod för datorseende, som innefattar ett antal bibliotek för datorseende i realtid baserat på C/C++
* OpenCL – öppen källkod för dataspråk baserat på C++ för utveckling av program för parallellbehandlade program, som i GPU, FPGA etc.
* SDSoC – Xilinx-designmiljö som möjliggör för utvecklare att först implementera algoritmer skrivna i C/C++ i ARM-behandlingssystemet hos en Zynq- eller UltraScale+ MPSoC-enhet, profilera kodbasen för att kunna identifiera prestandaflaskhalsar och sedan använda Xilinx-högnivåsyntes (HLS) för att översätta flaskhalsarna till maskinvaruaktiverad IP som körs i enhetens programmerbara logikdel (PL).

Användning av dessa ramverk tillsammans med HLS i en FPGA- eller ett All Programmable SoC-designflöde möjliggör effektiv utveckling av inbäddade kamerasystemprogram som snabbt kan visas med maskinvara i loopen.

Behandlingsalternativ
När bilden har gått igenom behandlingspipelinen är det viktigt hur data kommer ut ur systemet. På den högsta nivån finns det tre stora val. Ett av dessa är att överföra bilden till en skärm med en standard som VGA, HDMI, SDI eller DisplayPort. Eller så kan bilden (eller information som extraherats från den) överföras någon annanstans, till exempel till molnet, för ytterligare behandling. Ett tredje alternativ är att bilder lagras på beständiga media för att användas vid ett senare tillfälle.

För de flesta av de här alternativen på hög nivå vid slutförandet av bildkedjan är det viktigt att tänka på vilket bildformat som ska användas. Valet av bildkodning med en komprimeringsalgoritm med branschstandard som H.264 (MPEG-4 del 10, avancerad videokodning) eller H.265 (högeffektiv videokodning). Implementeringar av dessa algoritmer kallas ofta kodekar och tillåter effektivare utnyttjande av kommunikations- och nätverksbandbredd eller minskad lagringsyta, på bekostnad av en liten förlust av återgivningskvaliteten. I tillämpningar där sådana förluster inte är godtagbara kan bilden skickas eller lagras i dess raw-format eller kodad i ett förlustfritt format.

De flesta kodek-implementeringar använder en annan färgrymd än den som är utdata från typiska färgbildssensorer. De vanligaste färgrymderna som används inom inbäddade kamerasystem är:

* Röd, grön, blå – innehåller RGB-information som utdata från bildsensorn och används ofta som utdata för enkla gränssnitt som VGA
* YUV – innehåller luma (Y) och krominans (U och V) och används för de flesta kodekar och vissa skärmstandarder. Vanliga format är YUV4:4:4 och YUV4:2:2. Med 4:4:4 representeras varje pixel av åtta bitar för att skapa en 24-bitars pixel. Med ett 4:2:2-format delas U- och V-värdena mellan bildpunkter vilket ger ett mer minneseffektivt 16-bitars bildpunktsdjup.

Ett ytterligare beslut som har en stor inverkan på bildbehandlingskedjan och SWaP-C är valet av var de flesta bildbehandlingarna ska implementeras. Det kan vara inom det inbäddade kamerasystemet, vilket ger snabbare svarstider men även kräver högre behandlings- och minnesresurser, vilket leder till större strömförbrukning. Det här är den vanligaste metoden för inbäddade tillämpningar som ADAS eller maskinseende.

Alternativt kräver behandling som utförs i molnet att det inbäddade kamerasystemet kan ta bilden och överföra den med nätverkskompatibel teknik. Det här kan vara lämpligt för tillämpningar som bildbehandling inom medicin eller vetenskaplig forskning, där bearbetningen kan vara särskilt intensiv och resultat i realtid inte är ett krav.

För att kunna implementera behandlingskedjan kräver kärnan av ett inbäddat kamerasystem en processorkärna som inte bara kan styra den valda bildsensorn utan även ta emot, implementera bildbehandlingspipelinen och överföra bilder över önskad nätverksinfrastruktur eller till önskad skärm. De här stora kraven resulterar ofta i ett val av en FPGA eller som i allt fler fall i ett All Programmable System på ett chip.

Xilinx Zynq All Programmable SoCs kombinerar två högpresterande ARM A9-processorer med FPGA-struktur. Processorsystemet (PS) kan användas för att kommunicera med en värd över Gigabit Ethernet, PCIe eller andra gränssnitt som CAN samtidigt som det utför allmänt underhåll av systemet. Avsnittet med programmerbar logik (PL) utnyttjar den parallella inbyggda FPGA-strukturen för att ta emot och behandla bilderna mycket effektivt.

Om bilderna måste skickas över ett nätverk kan direkt minnesöverföring (DMA)-styrenheter på chippet användas för att effektivt flytta bilddata från PL till DDR-minne i PS. Bilddata kan även öppnas med DMA-styrenheter för det valda transportmediet inom PS DDR-minnet. Det är värt att notera att A9-processorer kan användas för att behandla bilden ytterligare i PS DDR och att Zynq-arkitekturen även låter behandlade bilder flyttas från PS DDR tillbaka till bildens pipeline i PL och på så sätt ge maximal flexibilitet att välja den mest effektiva behandlingsstrategin. Figur 2 visar den höga integreringen av behandling, minnesstyrning och gränssnittsfunktioner i Zyng-enheten.

Fig 2. Bildbehandlingsresurser i Zynq All Programmable SoC (klicka för större bild)

Sammanfattning
Efter vägledningen i sensorval i den första delen av serien har ett antal tekniker, ramverk och enheter som kan användas för att uppfylla strikta storleks-, vikt- och kostnadsbegränsningar (SWaP-C) på högpresterande inbäddade kamerasystem för krävande tillämpningar beskrivits i denna artikel.
Aaron Behman, Director of Strategic Marketing, Embedded Vision, Xilinx, Inc.
Adam Taylor CEng FIET, Embedded Systems Consultant.

Filed under: Embedded