<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
***: shuah has quit IRC (Quit: Leaving)
<br> iive has quit IRC (Quit: They came for me...)
ndufresne: <u>Kwiboo</u>: interesting, we are working on wrapping the ref software, but perhaps something get broke in the conversion
<br> the ref software run conformance using tiled and sw convert
***: _abbenormal has quit IRC (Read error: Connection reset by peer)
<br> NiksDev has quit IRC (Ping timeout: 260 seconds)
<br> bingbu has quit IRC (Ping timeout: 256 seconds)
<br> kaspter has quit IRC (Ping timeout: 240 seconds)
<br> nsekhar has quit IRC (Remote host closed the connection)
jernej: <u>ndufresne</u>: I inspected vp8 only visually
Kwiboo: <u>jernej</u>: you could use something like this to test with ffmpeg: ffmpeg -loglevel warning -hwaccel_device /dev/dri/card0 -hwaccel drm -hwaccel_output_format drm_prime -i vp80-00-comprehensive-006.ivf -vf hwdownload,format=nv12 -pix_fmt yuv420p -f framemd5 -
<br> and compare to https://github.com/webmproject/vp8-test-vectors/blob/master/vp80-00-comprehensive-006.ivf.md5
***: postmodern has quit IRC (Quit: Leaving)
<br> syoung has quit IRC (Quit: leaving)
mort: I have an ov5645. The ov5645 driver supports a few ctrls: https://github.com/varigit/DART-SD410-kernel/blob/release/kernel-17.06.1/drivers/media/i2c/ov5645.c#L871 - however, v4l2-ctl reports that the driver is qcom-camss, so I assume qcom-camss is somehow between userspace and that ov5645.c file (or maybe the ov5645 file only deals with i2c stuff,
<br> and qcom-camss uses the faster protocol to get the actual frames?)
<br> in any case, I have a camera device with no controls, even though there are obviously a few controls which the camera should support. How can I set those controls even though the camera device in /dev is using the qcom-camss driver? How do I interact with the stuff in ov5645.c? Or alternatively, could someone explain how this stuff fits together a
<br> bit more?
<br> fwiw, the driver that's actually reported for the device by video4linux is at https://github.com/varigit/DART-SD410-kernel/tree/release/kernel-17.06.1/drivers/media/platform/qcom/camss-8x16
pinchartl: <u>mort</u>: does the camss driver expose a media controller device ? what's the output of ls -l /sys/bus/media/devices/ ?
mort: oh, yes, we do have a /dev/media1. Is the ov5645 driver configured using the media controller and not the video device?
<br> <u>pinchartl</u>: our graph looks like this: https://p.mort.coffee/znD.png - I guess that top node, ov5645 at /dev/v4l-subdev10, is the thing that's actually controlled by the ov5645 driver. How can I query its controls?
<br> v4l2-ctl doesn't seem very happy with working on subdevs
***: svarbanov has quit IRC (Ping timeout: 265 seconds)
pinchartl: yavta --no-query -l /dev/v4l-subdev10
mort: didn't know about yavta, seems useful
***: marvs has quit IRC (Ping timeout: 256 seconds)
mort: ok, so my core issue is that the image from the camera looks very green. I thought it was a white balance issue, but it turns out auto white balance is enabled; it's just even more green without auto white balance.
<br> this suggests that we may be misinterpreting the output from the camera somehow. I assumed it was outputting regular YCbCr which can be converted to RGB using the standard YCbCr->RGB conversion, but maybe that's not the case.
pinchartl: can you share a sample picture ?
mort: alright, sec
<br> <u>pinchartl</u>: https://p.mort.coffee/N1J.data is the raw data; the settings on rawpixels.net which makes it show up "correctly" is 640x416 NV21
<br> that's with auto white balance, https://p.mort.coffee/JNf.data is without
<br> https://p.mort.coffee/a/iiv&XY2.png here are the two images rendered and screenshotted
<br> that wall is white
pinchartl: that looks like incorrect white balance to me
mort: we could disable auto white balance and do it manually
<br> well
<br> I don't think the driver exposes white balance settings
<br> should be relatively easy to patch in though
pinchartl: the camss shouldn't influence the colours, and while picking incorrect YUV encoding parameters when converting the NV12 data to RGB can cause colours to be off, the effect shouldn't be as strong as what you're seeing
<br> (Hans is our colourspace specialist, so he can correct me if I'm wrong)
mort: I'm trying to look through all the registers which are set now by ovh5645.c
<br> the first setting, { 0x3103, 0x11 }, seems to mess with values where https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf says "Changing this value is not allowed"
<br> I don't know if that spec sheet is correct or not for this camera, but it's the closest I've been able to find and 5645 should be fairly close to 5640...
pinchartl: omnivision datasheets are always incorrect
<br> there are lots of registers that are not listed
<br> or register fields
mort: how did y'all figure out what registers to set then in the driver?
pinchartl: they're usually provided by the omnivision technical support, to SoC vendors or integrators
<br> in the form of register addresses and values, without any explanation
<br> it's a mess
mort: oh, super fun.
pinchartl: that's why I always recommend on semi camera sensors instead of omnivision
mort: I'll keep that in mind for whenever I happen to be put in charge of selecting a new camera sensor
<br> for the foreseeable future, this is what we got to work with :p
<br> I can try to obtain a datasheet for the correct camera though, maybe that's at least slightly more correct
pinchartl: as for for register 0x3103 the OV5645 datasheet doesn't document bits 7:2 and 0 either
<br> s/as for //
mort: alright, datasheet obtained
<br> I think this datasheet is some kind of NDA encumbered... but I can probably share that 0x3103 is identical, so it does indeed set two bits which are only documented as "debug mode" as the ov5640 datasheet suggests
<br> nice
***: frispete has quit IRC (Quit: Konversation terminated!)
<br> taliho has quit IRC (Ping timeout: 260 seconds)
<br> lexano has quit IRC (Ping timeout: 246 seconds)
<br> YuGiOhJCJ has quit IRC (Quit: YuGiOhJCJ)
<br> R0b0t1 has quit IRC (Ping timeout: 265 seconds)
<br> ezequielg_6 has left
<br> mtretter has quit IRC (Ping timeout: 264 seconds)
<br> Kwiboo has quit IRC (Quit: .)