search

treeswift / l16-community

Umbrella project for L16 camera support and, God willing, revival
The Unlicense
1 stars 0 forks source link

some useful information #4

Open lumeyisnotyou opened 1 week ago

lumeyisnotyou commented 1 week ago

hello there! i run the light discord and someone posted this repo; we thought it would be a good idea to provide a link to our discord. if you're not a fan of discord, i'll leave you our #useful-links channel's content:

Most everything related to the camera, you will find here:

General Info

XDA Developers Thread: https://forum.xda-developers.com/t/light-l16-firmware.4403267/ helloavo's Archival Repository https://github.com/helloavo/Light-L16-Archive/

Reverse Engineering

https://github.com/gennyble/lri-rs https://github.com/ookami125/openlight-camera

If I am missing anything you think should be in here, please let me know!

treeswift commented 1 week ago

A really helpful overview, thank you! Adding the contents of your post to the front page, with attribution.

treeswift commented 1 week ago

Done. You can check if it looks good now. I'd keep this issue open because it's a convenient place for people to post more links.

lumeyisnotyou commented 1 week ago

all looks good! thanks for taking interest in this, we all want a more-functional camera!

treeswift commented 1 week ago

Same here. Just curious, beyond decoding the format, did anyone try recreating the image fusion algorithms from open publications, given the recent (6+ years) progress in the tech? E.g., to the best of my knowledge, Lumen doesn't use GPU for fusion, only for image display (as one can tell by the CPU/GPU use during image processing). Did anyone you know or knew of try fusing on GPU?

treeswift commented 1 week ago

I am currently considering a very limited use case, which is using the camera for scanning a large array of documents and processing them into a navigable archive. In qualitative terms, the limitation can be described as follows: it is relatively safe to assume that the variations in patch displacement along a stereo baseline are of the same or lesser magnitude as/than the patch/kernel size (i.e. there are no prominent background or foreground elements relative to most of the scene).

ookami125 commented 1 week ago

I was planning on doing something at one point myself, I've done experimenting with colmap and such in the past and was planning on using that. I was waiting for our image extraction to get a bit better though since most of the images I take result in giant pink blobs.

treeswift commented 1 week ago

Raw images are supposed to look that way, as the sensor itself knows nothing about the white balance and such. If at least the contours are right, you are on the right track.

ookami125 commented 1 week ago

I will admit, I'm not much of a photographer so I'm not super knowledgeable on image processing outside of games. But with the current converter everything is exported to png and the pink spots are clipped, so no detail in those areas remain. There is a plan to output dng files, but I think with the current setup that information is lost not just incorrect. I would like to be proven wrong though.

gennyble commented 1 week ago

The pinkness is my fault and is due to my lack of gammut clipping. the issue is here: https://github.com/gennyble/lri-rs/issues/3

@treeswift The code in that repository parses the LRI file and exports the images as too-big PNG files. I use the metadata to try and do colour correction but it does not go very well! There's also an issue to export DNG (https://github.com/gennyble/lri-rs/issues/4) that I need to get to doing.

I wrote a document that may be of use a few months ago: https://github.com/gennyble/lri-rs/blob/main/LRI.md