The Netherlands
I do computer stuff
Comment by ~martijnbraam on ~martijnbraam/Megapixels
This should be fixed in the 0.14 release which doesn't hardcode ~/Pictures anymore. But that release is pretty recent, not sure if it's in mobian yet.
Ticket created by ~martijnbraam on ~martijnbraam/Megapixels
The "raw" pixels from the ov5640 are 8 bit raw and the whitebalance is done by adjusting the R/G/B gains in the analog part of the chip.
DNG raw expects the raw data to not be whitebalanced and have the R/G/B gains for what the camera decided was "camera neutral" stored in metadata. The way to fix this would be to scale up the 8 bit data to 16 bit channels and then multiply the color channels with the inverse of the analog gain in the sensor and then write the gains as metadata in the DNG file.
This way photo processing apps can show the right white balance, but more importantly: without the correct whitebalance the second set of colormatrices in the dng can't be used since they are interpolated based on the whitebalance metadata. The current DNGS are single-illuminant calibrated for D65 light and look way worse when photos are made indoor.
Comment by ~martijnbraam on ~martijnbraam/Megapixels
Doing realtime QR detection in the preview probably won't work that well on the pinephone. We also already pull in imagemagic for the post-processing (but I want to get rid of that).
The issue with headerbars is that megapixels isn't only used in phosh. And outside of phosh it looks pretty weird to have a headerbar. It's also used in plasma mobile currently for example. The nice thing about the non-headerbar header is that plasma mobile can just cut it off to have more screen space. At most it would be something optional, but that would be even more code.
One idea i had is have a row of modes in the bottom of the preview as overlay, just like some android cameras do to switch between picture/portrait/movie/slowmo and that can have a picture/qr switch and in the future maybe more random modes.
Comment by ~martijnbraam on ~martijnbraam/Megapixels
I haven't really encountered any fully undocumented registers, they are usually just badly documented or documented in seperate appnotes (like for autofocus)
This is the manual I've been using: https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf
I expect there are a bunch of issues with my autofocus patch, which can raise an ETIMEOUT error in places where vl42 doesn't expect it.
The flash_strobe isn't super short so it shouldn't really have timing issues, especially since we mostly use the first frame now in postprocessing. Having the timing regulated by v4l2 is definetly nicer though.
Bug added by ~martijnbraam on ~martijnbraam/Megapixels
Comment by ~martijnbraam on ~martijnbraam/Megapixels
Fixed in 0.14.0
REPORTED RESOLVED FIXED
Comment by ~martijnbraam on ~martijnbraam/Megapixels
This is merged in 0.14
REPORTED RESOLVED FIXED
Comment by ~martijnbraam on ~martijnbraam/Megapixels
Merged that change, thanks Benjamin :)
REPORTED RESOLVED FIXED
Comment by ~martijnbraam on ~martijnbraam/Megapixels
Fixed in 0.14, thanks to Benjamin :)
REPORTED RESOLVED FIXED
Comment by ~martijnbraam on ~martijnbraam/Megapixels
looks like your current implementation uses sysfs to talk to the leds, which isn't the ideal way to do this. v4l2 has an interface to integrate the flash led which the flash driver for the PinePhone supports, but we're having some issues with that driver when it actually integrates in the dtb so it's currently disabled. Using the leds directly with sysfs has some permission issues.
Also for the flash sysfs interface it shouldn't use the max_brightness stuff since that's for torch mode, not flashing. For flashing you write to the flash_strobe file which fires the led for a short duration, but way brighter.