Re: V4L2_PIX_FMT_RAW
H. Willstrand wrote:
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
Yes, raw means "as it is" no stripping, decoding or removing of SOF headers are
done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?
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
--
http://www.kaiser-linux.li
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list