linux-kernel - Re: [RFC] v4l2 support for thermopile devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 28 Oct 2016 16:30:12 -0400
From:   Devin Heitmueller <dheitmueller@...nellabs.com>
To:     Matt Ranostay <matt@...ostay.consulting>
Cc:     Linux Media Mailing List <linux-media@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Attila Kinali <attila@...ali.ch>, Marek Vasut <marex@...x.de>
Subject: Re: [RFC] v4l2 support for thermopile devices

Hi Matt,

> Need some input for the video pixel data types, which the device we
> are using (see datasheet links below) is outputting pixel data in
> little endian 16-bit of which a 12-bits signed value is used.  Does it
> make sense to do some basic processing on the data since greyscale is
> going to look weird with temperatures under 0C degrees? Namely a cold
> object is going to be brighter than the hottest object it could read.
> Or should a new V4L2_PIX_FMT_* be defined and processing done in
> software?  Another issue is how to report the scaling value of 0.25 C
> for each LSB of the pixels to the respecting recording application.

Regarding the format for the pixel data:  I did some research into
this when doing some driver work for the Seek Thermal (a product
similar to the FLIR Lepton).  While it would be nice to be able to use
an existing application like VLC or gStreamer to just take the video
and capture from the V4L2 interface with no additional userland code,
the reality is that how you colorize the data is going to be highly
user specific (e.g. what thermal ranges to show with what colors,
etc).  If your goal is really to do a V4L2 driver which returns the
raw data, then you're probably best returning it in the native
greyscale format (whether that be an existing V4L2 PIX_FMT or a new
one needs to be defined), and then in software you can figure out how
to colorize it.

Just my opinion though....

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com