* [RFC] media: thermal I2C cameras metadata @ 2018-07-16 6:05 Matt Ranostay 2018-07-23 11:35 ` Sakari Ailus 0 siblings, 1 reply; 5+ messages in thread From: Matt Ranostay @ 2018-07-16 6:05 UTC (permalink / raw) To: linux-media Hello et all, So currently working with some thermal sensors that have coefficients that needs to be passed back to userspace that aren't related to the pixel data but are required to normalize to remove scan patterns and temp gradients. Was wondering the best way to do this, and hope it isn't some is kludge of the close captioning, or just passing raw data as another column line. Datasheet: https://www.melexis.com/en/product/MLX90640/Far-Infrared-Thermal-Sensor-Array Thanks, Matt ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] media: thermal I2C cameras metadata 2018-07-16 6:05 [RFC] media: thermal I2C cameras metadata Matt Ranostay @ 2018-07-23 11:35 ` Sakari Ailus 2018-07-25 6:05 ` Matt Ranostay 0 siblings, 1 reply; 5+ messages in thread From: Sakari Ailus @ 2018-07-23 11:35 UTC (permalink / raw) To: Matt Ranostay; +Cc: linux-media Hi Matt, On Sun, Jul 15, 2018 at 11:05:42PM -0700, Matt Ranostay wrote: > Hello et all, > > So currently working with some thermal sensors that have coefficients > that needs to be passed back to userspace that aren't related to the > pixel data but are required to normalize to remove scan patterns and > temp gradients. Was wondering the best way to do this, and hope it > isn't some is kludge of the close captioning, or just passing raw data > as another column line. Are you referring to the EEPROM content or something else? For EEPROM, I could think of just exposing the EEPROM to the user space as-is using the NVMEM API. This information is very, very device specific and therefore using a generic interface to access individual values there isn't really useful. -- Sakari Ailus e-mail: sakari.ailus@iki.fi ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] media: thermal I2C cameras metadata 2018-07-23 11:35 ` Sakari Ailus @ 2018-07-25 6:05 ` Matt Ranostay 2018-07-25 9:09 ` Sakari Ailus 0 siblings, 1 reply; 5+ messages in thread From: Matt Ranostay @ 2018-07-25 6:05 UTC (permalink / raw) To: Sakari Ailus; +Cc: linux-media On Mon, Jul 23, 2018 at 4:35 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote: > Hi Matt, > > On Sun, Jul 15, 2018 at 11:05:42PM -0700, Matt Ranostay wrote: >> Hello et all, >> >> So currently working with some thermal sensors that have coefficients >> that needs to be passed back to userspace that aren't related to the >> pixel data but are required to normalize to remove scan patterns and >> temp gradients. Was wondering the best way to do this, and hope it >> isn't some is kludge of the close captioning, or just passing raw data >> as another column line. > > Are you referring to the EEPROM content or something else? > > For EEPROM, I could think of just exposing the EEPROM to the user space > as-is using the NVMEM API. This information is very, very device specific > and therefore using a generic interface to access individual values there > isn't really useful. > Actually that is okay for the EEPROM data that is per sensor, and nvram does seem like it would work. But there is per video frame data that is required along with the static EEPROM data to calculate the actual end result. - Matt > -- > Sakari Ailus > e-mail: sakari.ailus@iki.fi ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] media: thermal I2C cameras metadata 2018-07-25 6:05 ` Matt Ranostay @ 2018-07-25 9:09 ` Sakari Ailus 2018-07-25 23:29 ` Matt Ranostay 0 siblings, 1 reply; 5+ messages in thread From: Sakari Ailus @ 2018-07-25 9:09 UTC (permalink / raw) To: Matt Ranostay; +Cc: linux-media On Tue, Jul 24, 2018 at 11:05:47PM -0700, Matt Ranostay wrote: > On Mon, Jul 23, 2018 at 4:35 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote: > > Hi Matt, > > > > On Sun, Jul 15, 2018 at 11:05:42PM -0700, Matt Ranostay wrote: > >> Hello et all, > >> > >> So currently working with some thermal sensors that have coefficients > >> that needs to be passed back to userspace that aren't related to the > >> pixel data but are required to normalize to remove scan patterns and > >> temp gradients. Was wondering the best way to do this, and hope it > >> isn't some is kludge of the close captioning, or just passing raw data > >> as another column line. > > > > Are you referring to the EEPROM content or something else? > > > > For EEPROM, I could think of just exposing the EEPROM to the user space > > as-is using the NVMEM API. This information is very, very device specific > > and therefore using a generic interface to access individual values there > > isn't really useful. > > > > Actually that is okay for the EEPROM data that is per sensor, and > nvram does seem like it would work. > But there is per video frame data that is required along with the > static EEPROM data to calculate the actual end result. Could you point out what that might be on the datasheet? -- Sakari Ailus e-mail: sakari.ailus@iki.fi ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] media: thermal I2C cameras metadata 2018-07-25 9:09 ` Sakari Ailus @ 2018-07-25 23:29 ` Matt Ranostay 0 siblings, 0 replies; 5+ messages in thread From: Matt Ranostay @ 2018-07-25 23:29 UTC (permalink / raw) To: Sakari Ailus; +Cc: linux-media On Wed, Jul 25, 2018 at 2:09 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote: > On Tue, Jul 24, 2018 at 11:05:47PM -0700, Matt Ranostay wrote: >> On Mon, Jul 23, 2018 at 4:35 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote: >> > Hi Matt, >> > >> > On Sun, Jul 15, 2018 at 11:05:42PM -0700, Matt Ranostay wrote: >> >> Hello et all, >> >> >> >> So currently working with some thermal sensors that have coefficients >> >> that needs to be passed back to userspace that aren't related to the >> >> pixel data but are required to normalize to remove scan patterns and >> >> temp gradients. Was wondering the best way to do this, and hope it >> >> isn't some is kludge of the close captioning, or just passing raw data >> >> as another column line. >> > >> > Are you referring to the EEPROM content or something else? >> > >> > For EEPROM, I could think of just exposing the EEPROM to the user space >> > as-is using the NVMEM API. This information is very, very device specific >> > and therefore using a generic interface to access individual values there >> > isn't really useful. >> > >> >> Actually that is okay for the EEPROM data that is per sensor, and >> nvram does seem like it would work. >> But there is per video frame data that is required along with the >> static EEPROM data to calculate the actual end result. > > Could you point out what that might be on the datasheet? Datasheet: https://www.melexis.com/-/media/files/documents/datasheets/mlx90640-datasheet-melexis.pdf On page 18 it documents that 0x700-0x73f are required for the various userspace calculations along with the other static EEPROM data. > > -- > Sakari Ailus > e-mail: sakari.ailus@iki.fi ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-07-26 0:43 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-16 6:05 [RFC] media: thermal I2C cameras metadata Matt Ranostay 2018-07-23 11:35 ` Sakari Ailus 2018-07-25 6:05 ` Matt Ranostay 2018-07-25 9:09 ` Sakari Ailus 2018-07-25 23:29 ` Matt Ranostay
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.