Web lists-archives.org

Re: V4L2_PIX_FMT_RAW

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
>
>
>
>
> --
>  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