Re: V4L2_PIX_FMT_RAW

["H. Willstrand" <h.willstrand@xxxxxxxxx>]

On Thu, Feb 21, 2008 at 2:20 AM, Daniel Glöckner <daniel-gl@xxxxxxx> wrote:
> On Thu, Feb 21, 2008 at 01:02:39AM +0100, H. Willstrand wrote:
>  > What's the problem with having a name of the formalized data in the
>  > video stream? ie raw do not mean undefined.
>
>  I thought you wanted to avoid having to define V4L2_PIX_FMT_x for an
>  exploding number of proprietary formats that are quite similar but still
>  incompatible. It makes sense for formats that are used by more than one
>  driver.

Correct, the number of unique pixel formats should be kept down.
Again, comparing with digital cameras there are >200 proprietary
formats and there is a "clean-up" on-going where the "market" is
aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver
specific) doesn't help the user mode app developers. Calling a
multitude of libraries to see if you get lucky might not be a good
idea.

Still, I'm suspectious about the definition "raw" used here.
RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

So, by looking for similarities in the "raw" formats where available
there should be a potential to consolidate them.

>
>
>  > I don't see how separate RAW ioctl's will add value to the V4l2 API,
>  > it fits into the current API.
>
>  Yes, it does. Each driver having multiple raw formats just needs a
>  private control id to select one.
>
I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT
should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Harri

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list