Just took a quick poke at marshallh's 4.tdc capture (no particular reason I chose to poke that one).
Hi marshallh *waves back* seems the brief video in 4.tdc came through nicely
Frame size is 64896 bytes, there is no header. Frames are sent at roughly 8fps in the 4.tdc capture, didn't look closely at others. The control transfer is a frame request, it's sent before every frame so I don't think it's a shutter calibration request.
Frame consists of 208x156 pixels, each pixel is 16bits, with only 14bit effective. Little endian.
The last 2 columns are not image data:
- The second-to-last column might be a CRC16 or simple checksum, I'm not sure. It seems strongly correlated to the row pixel data so maybe it's some sort of histogram data or something?
- The last column is all 0x0000's in valid frames, it seems. It looks like occasionally the app requested frames faster than ~8fps, and the Seek responded with incomplete / misaligned frames.
One of those is attached (seek-3.png).
What's weird is these extremely low value (often 0000h) pixels, which are pretty uniformly spread throughout the frame... See attached seek-0.png frame for an example which has been auto-level'd to make them more obvious. Maybe calibration pixels of some sort? I'm really not sure at all. They seem to be in fixed positions throughout the image though, across the entire image stream in 4.tdc. No time to investigate closer.
The B&W images were created by dumping the frame endpoint data to a .bin file, then using this command (ImageMagick convert):
convert -depth 16 -endian lsb -size 208x156 gray:epdump.bin -auto-level seek.png
If epdump.bin contains many images (dump an entire stream) this will dump all of them to separate files named seek-0.png, seek-1.png, etc.
The color image was trickier. The images this thing spits out are probably straight off the sensor with
zero processing -- they're noisy as hell, unlike the FLIR ONE's image stream which is pre-digested by the Lepton core. This means the flat field correction and such is likely done in software, not even in the Seek itself. So to get the color image, I applied some manual level adjustments as I think the dark pixels were throwing off convert's auto leveling... then I took a frame from the start of 4.tdc which looked very uniform and subtracted the two frames. From there I colorized it with the typical "ironbow" palette again using convert:
convert marshallh-wave.png ..\palette.png -clut marshallh-wave-colorized.png
Anyway, no time to poke this further tonight but thought I'd share my findings. Hope it helps!
Home
Help
Search
Login
Register
