| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | mchehab has quit IRC (Read error: Connection reset by peer) | [00:05] |
| .................. (idle for 1h29mn) | ||
| DaRock has quit IRC (Ping timeout: 268 seconds) | [01:34] | |
| .... (idle for 15mn) | ||
| gnurou | hverkuil: yes you *are* good! :) Please take your time for the review. By then I will likely submit a v3 with the proper QBUF behavior
hverkuil: we may come back to you to confirm that our understanding is correct though, if you can just dedicate the time to validate this that would be perfect | [01:49] |
| ..................................................................................................... (idle for 8h22mn) | ||
| pinchartl | hverkuil: ping | [10:11] |
| hverkuil | pinchartl: pong | [10:12] |
| pinchartl | in your colorspace experience, do camera sensors use a transfer function, or do they usually output linear RGB/YUV values ?
s/use/implement/ I would expect the CMOS cells to react linearly to the input power | [10:12] |
| hverkuil | Frankly, it is usually raw. I.e., for sensors you typically need to map the values on a curve. | [10:14] |
| pinchartl | so it's linear RGB, not R'G'B', right ? | [10:14] |
| hverkuil | Neither. As far as I know we always have to convert the values according to some sensor specific curve in order to get the correct colors. | [10:15] |
| pinchartl | (Kieran asks whether you'll attend the FOSDEM)
hmmmm... yes, sensor datasheets usually document the color sensitivity curves | [10:15] |
| hverkuil | V4L2 typically sets the colorspace to SRGB, which is probably wrong for almost all sensors. It should be RAW, but nobody handles that anyway.
No, I'm not attending fosdem this year. | [10:16] |
| pinchartl | ok so
if I undestand it correctly the human eye has a spectrum response curve and camera sensors can have a different one so mapping is needed to go from sensor RGB to CIE XYZ but apart from that sensors usually don't have a transfer function | [10:17] |
| hverkuil | Right. Typically USB and HDMI cameras have that mapping internally and will convert the sensor data to sRGB or BT.601 or something like that (i.e. following a standard). | [10:18] |
| pinchartl | they produce linear values, proportional to the input power | [10:18] |
| hverkuil | On embedded systems it is something the developer has to implement. | [10:19] |
| pinchartl | is my understanding correct ? | [10:19] |
| pH5 | pinchartl: some sensors, like the mt9v024, have hdr exposure mode with a configurable piecewise linear response and a non-linear 12->10-bit companding scheme | [10:19] |
| pinchartl | linear values but not in a CIZ XYZ colorspace, they have their own spectral response curve
pH5: thanks | [10:19] |
| hverkuil | I don't think sensors are necessarily linear (or at all). It depends on the technical details. I'm not the expert on that, though. | [10:20] |
| pinchartl | hverkuil: ok, no worries. do you think the non-linearity would come from the way the CMOS cell works, or from processing in the sensor ? | [10:20] |
| hverkuil | Advanced cameras typically have a RAW mode, and software that can process that has to know the curve. | [10:20] |
| pinchartl | I wouldn't call a $0.10 omnivision sensor an advanced camera ;-) | [10:21] |
| hverkuil | Probably the CMOS, I don't think sensors do much color processing. | [10:21] |
| pinchartl | but I get your point
so my question is what should I report for the sensor colorspace ? :) ycbcr_enc is easy | [10:21] |
| hverkuil | I never dug deep into sensor technology. | [10:22] |
| pinchartl | quantization too
but xfer_func ? V4L2_XFER_FUNC_NONE ? and V4L2_COLORSPACE_RAW for colorspace I assume | [10:22] |
| hverkuil | There are two options for the colorspace: COLORSPACE_RAW (probably correct, but this might cause compatibility problems) or COLORSPACE_SRGB (probably wrong, but more likely to work). In both cased just set xfer_func to the XFER_FUNC_DEFAULT.
I've been thinking about changing the colorspace for all sensor drivers to RAW, but I don't know what the fall-out of that would be. | [10:23] |
| pinchartl | COLORSPACE_SRGB + XFER_FUNC_DEFAULT is well-defined in the spec but most likely wrong. COLORSPACE_RAW + XFER_FUNC_DEFAULT is also well-defined and means V4L2_XFER_FUNC_NONE
is there a reason to report xfer_func = XFER_FUNC_DEFAULT instead of xfer_func = XFER_FUNC_DEFAULT ? | [10:25] |
| hverkuil | you mean DEFAULT vs NONE, I guess. | [10:26] |
| pinchartl | I thought the *_DEFAULT values were there for backward-compatibility and the drivers that handle colorspaces should report an explicit xfer function, not use XFER_FUNC_DEFAULT
yes, sorry, I meant DEFAULT vs. NONE I'd prefer setting it to NONE, it's more explicit | [10:26] |
| hverkuil | It's up to the driver. Applications will have to be able to handle DEFAULT regardless, since so few drivers are explicit. So I'm fine with either.
Generally I keep it to DEFAULT for well defined colorspaces (sRGB, 601, 709) and be explicit when you get to unusual colorspaces. But it's really up to you. | [10:28] |
| pinchartl | thank you for your help | [10:29] |
| hverkuil | Happy to help! | [10:30] |
| ..... (idle for 21mn) | ||
| jmondi: I have updated v4l2-ctl with support for v4l-subdev device nodes. Could you test this on the renesas board? v4l2-ctl --help-subdev gives more information.
I couldn't test all ioctls since not everything is supported in vimc. | [10:51] | |
| ..... (idle for 20mn) | ||
| *** | juvenal has quit IRC (Ping timeout: 276 seconds)
arnd has quit IRC (Ping timeout: 276 seconds) | [11:11] |
| jmondi | hverkuil: sure! I will probably post pone this to next week (as I'm doing for CEU).. is this ok? | [11:23] |
| hverkuil | no problem | [11:23] |
| jmondi | hverkuil: btw, are you happy with the current state of ov772x frame interval handling?
I didn't get if the issue you mentioned when discussing with Laurent yesterda is there or in how the ceu driver handles driver that do not implement enum_frame_interval() :) | [11:23] |
| hverkuil | I'm happy with the v8 patch.
BTW, I hope to make some time to add v4l-subdev support to v4l2-compliance as well. We really need some better testing (and yes, v4l2-compliance will be limited in scope since it is only testing one subdev, but that's still better than nothing). | [11:28] |
| jmondi | hverkuil: great. Next week I'll test v4l2-compliance on the ceu connected to a sensor driver without enum_frame_intervals() and see if that triggers any errors (because if I'm not wrong there is a test that wants to make sure s_parm is not available if no enum_frame_interval is there) | [11:30] |
| ................................................................ (idle for 5h17mn) | ||
| *** | benjiG has left | [16:47] |
| ............................................................ (idle for 4h59mn) | ||
| strfry has quit IRC (Ping timeout: 265 seconds) | [21:46] | |
| pocek has quit IRC (Ping timeout: 268 seconds) | [21:55] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |