Re: V4L2_PIX_FMT_RAW
H. Willstrand wrote:
On Thu, Feb 21, 2008 at 1:00 PM, Thomas Kaiser
<linux-dvb@xxxxxxxxxxxxxxx> wrote:
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?
I struggle with the probability to find several CCD's having similar
formats. There aren't so many manifactors of CCD's but they truelly
can generate divergeting formats. Worst case scenario means >200
V4L2_PIX_FMT_RAW_...
I think RAW is a OK name, the question is if the subcomponents of the
RAW formats has similarities, if so they might be standardized.
Looking into different Sony CCD's it's clearly possible, but after the
CCD the data has to be buffered, packaged and transmitted which of
course can be done in several ways...
Cheers,
Harri
>
> 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
Actually, in a webcam you have the image sensor and a usb bridge. Usually, the
sensor capture a picture in Bayer pattern. This gets forwarded to the usb
bridge. The usb bridge may or may not transfer the picture to an other format
and/or compress it with a standard compression algo or a proprietary compression
algo. The resulting data stream will be transmitted over the usb interface.
I just would like to get this resulting stream to user space without
manipulation/conversion/decoding of the stream in the kernel module.
That means we don't know what the format is in this data which comes trough the
usb interface. That's way I call it raw.
At the moment with V4L2, I have to forward a stream to user space which is in a
format v4l2 knows. That means I have sometimes to do heavy data processing in
the kernel module to decode/convert the data from the usb stream to a known v4l2
video format.
That's way I want a official way to forward the untouched usb stream to user space!
How the user space application has to react on this stream is an other story, I
think. But there will be some way to tell the usespace application what to do
with this "unknown" stream, I am sure.
Thomas
--
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