ich hab mir mittlerweile den code noch ein bisserl genauer angesehen, um besser zu verstehen, auf welche daten da tatsächlich zugegriffen wird bzw. welche freihten sich daraus in der praxis ergeben.
grundsätzlich greift das ganze über die NDK (native development kit) kamera-schnittstelle auf die hardware zu. damit stehen zwar im grunde nur die selben möglichkeiten offen, die es auch davor schon im normalen android camera2-API gegeben hat, aber man kann es nun eben auch von von recht effizienten programmiersprachen aus bzw. verhältnismäßig hardwarenah nutzen, wie es im konkreten fall auch ausgesprochen vorbildlich umgesetzt wird.
ganz gut ist die entsprechenden herangehensweise in diesem artikel erklärt:
https://www.sisik.eu/blog/android/ndk/camera
was also die grundsätzlichen möglichkeiten des zugriffs auf die rohen sensor-daten angeht, ist mit dieser anwendung eigentlich nichts neues dazu gekommen, was nicht schon lange im android-umfeld möglich gewesen wäre.
worin sich allerdings diese app von den meisten ähnlichen anwendungen unterscheidet, ist einerseits die wunderbar effiziente implementierung in C++ und Halide, aber eben auch die tatsache, dass nur zum auslesen der RAW-daten auf die erwähnten NDK-APIs zurückgegriffen wird, alles andere aber in software innerhalb der app selebt aufbereitet wird. es wird also zumindest in der weiteren bildaufbereitung nicht auf jene mechanismen zurückgegriffen, die das system bzw. die hersteller des handys in der firmware dafür anbietet.
der großteil des codes betrifft diese routinen des bildaufbereitung.
und obwohl das natürlich auf den ersten blick für uns nicht ganz so spektakulär wirkt, ist es eine unglaubliche leistung, es so hinzubekommen, dass das tatsächlich befriedigend funktioniert. es ist auch deshalb so bedeutsam, weil es bisher oft notwendig war, auf gehackte ausgaben der unfreien google-camera-app zurückzugreifen, um auf android handys eine zufriedenstellendere bildaufbereitung zur verfügung zu haben als sie von den handyherstellern in vielen fällen bereitgestellt wird.
natürlich gibt's aber auch immer einzelne features bzw. eigenheiten der verbauten kamera- und bildaufbereitungshardware, die sich nur über die herstellerseitige apps od. propritäre nicht offengelegt APIs ansprechen und nutzen lassen. gerade um die hardwaredetails und eigenheiten der genutzten grafikeinheiten herrscht ja immer extrem viel geheinistuerei. trotzdem sind die offiziell vorgesehen android-kamera-schnittstellen ohnehin ziemlich toll und werden auch tatsächlich von den meisten herstellern einigermaßen zufriedenstellend unterstützt.
ein auslesen der RAW-daten -- ganz egal, ob als einzelnes standbild od. in kontinuierlichen sequenzen -- war also bei den besseren android devices immer schon möglich. für die auflösung bzw. bittiefe und anordnung der übergebenen daten stehen dabei die folgen vier möglichkeiten zur verfügung:
RAW10 -- Android 10-bit raw format
This is a single-plane, 10-bit per pixel, densely packed (in each row), unprocessed format, usually representing raw Bayer-pattern images coming from an image sensor.
RAW12 -- Android 12-bit raw format
This is a single-plane, 12-bit per pixel, densely packed (in each row), unprocessed format, usually representing raw Bayer-pattern images coming from an image sensor.
RAW_PRIVATE
Private raw camera sensor image format, a single channel image with implementation depedent pixel layout.
RAW_SENSOR
General raw camera sensor image format, usually representing a single-channel Bayer-mosaic image.
mit letzterer option erhält man in der regel die volle vom sensor bereitgestellte auflösung in 16bit breitem übergabeformat.
zu beachten ist auch noch, dass gerade bei den sensoren mit sehr hoher auflösung oft auch senselbinning genutzt bzw. konfiguriert werden kann, um den datenumfang zu reduzieren (SENSOR_INFO_BINNING_FACTOR). das betrifft dann natürlich auch die RAW daten.
die anfallenden datenmengen sind natürlich reativ groß und damit kaum wegzuschreiben.
android sieht zwar seit neustem leistungskassen-angaben (
performance-class) vor, die eben auch für diesen storage-durchsatz klare anforderungen spezifizieren:
for Android 12:
At least 6GB of RAM
At least 400dpi and 1080p resolution
At least 150MB/s sequential write, 250MB/s sequential read, 10MB/s random write, and 40MB/s random read speeds
allerdings sind diese werte realtiv nieder angesetzt, so dass auch ältere geräte der oberklasse leicht mithalten können -- bspw. mein nicht mehr wirklich aktuelles xiaomi MI8:
AndroBench.png
die frage ist also, ob man mit guten zeitgemäßen kompressionstechniken (z.b.
zstd,
lz4 od
snappy), das ausmaß der daten in echtzeit ausreichend weit reduzieren kann, um sie kontinuierlich wegschreiben zu können?
vermutlich dürften derartige strapazen dem internen speicher allerdings nicht wirklich gut tun, was man, neben einigen anderen nachteilen und problemen, vielleicht auch mitbedenken sollte.
was die von rocky angesprochenen probleme mit der P30 und P40 bzw. deren CFA-eigenheiten betrifft, bräuchte man vermutlich nur in die DNG-metadaten bzw. das dort eingebettete farbaufbereitunsprofil, die nötigen zusätzlichen angaben einfügen -- das wird hier in der vorliegenden app ohnehein in einem eigenen aufbereitungsschritt unabhängig von der eigentlichen aufzeichnung gemacht --, um das ganze in den meisten programmen verarbeitbar zu machen...
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.