about summary refs log tree commit diff
diff options
context:
space:
mode:
authorgennyble <gen@nyble.dev>2023-06-08 00:54:51 -0500
committergennyble <gen@nyble.dev>2023-06-08 00:54:51 -0500
commitaec3f2c27e228155bed768f9490a724de1f9bda3 (patch)
treeb8e68f54db18741c0b8c98441ddda1d829a6a542
parentf0ab93507bc7de8be6172768e19d6f9baa5e46e7 (diff)
downloadlri-rs-aec3f2c27e228155bed768f9490a724de1f9bda3.tar.gz
lri-rs-aec3f2c27e228155bed768f9490a724de1f9bda3.zip
readme
-rw-r--r--NOTES.md8
-rw-r--r--README.md5
2 files changed, 9 insertions, 4 deletions
diff --git a/NOTES.md b/NOTES.md
index eadb745..868a3f3 100644
--- a/NOTES.md
+++ b/NOTES.md
@@ -63,10 +63,12 @@ In the header, these should be reserved: all null. It matched 10 times and faile
 
 # Found some RAW data!!!!
 ## 2023-06-08 00:37 CST
-tired, need sleep.
+tired, need sleep, bullet point for now.
 - no "lost data"; all data is held by a LightHeader
 - it appears sometimes the length fields move around in `header_length` *(which is indeed sometimes set to the header length)* and the message length
-- lak was able to use SourceExplorer to figure out that, yeah, the data really is right after the LightHeader.
+- lak was able to use [SourceExplorer][se-dev] to figure out that, yeah, the data really is right after the LightHeader.
 - **thank you**
 - it appears to be 14bpp packed *(for wall.lri at least)*. the `camera_module.proto` has this as one of the raw options. we should make it a priority to find and parse this.
-- yay
\ No newline at end of file
+- yay
+
+[se-dev]: https://github.com/LAK132/SourceExplorer/tree/dev
\ No newline at end of file
diff --git a/README.md b/README.md
index 9d27d22..6a764e4 100644
--- a/README.md
+++ b/README.md
@@ -16,12 +16,14 @@ of the file header?
 Can we parse the message in the header with the protobuf as described in: [dllu/lri-rs](https://github.com/dllu/lri-rs/blob/main/proto/lightheader.proto)?
 
 ### File Header
-The file seems to consist of a header followed be a proto buf message
+The LightHeader seems to consist of a header followed be a proto buf message
 that then gets appended to it.
 
 The header is **little endian**
 
 #### File Header Structure
+This is only sometimes the case. It seems that "header length (32)" field is sometimes a lot *a lot* bigger. in that case you have the sensor data. perhaps then the message length is some inidication to protobuf data? perhaps it's nothing? padding?
+
 The header is 32 bytes long. and goes as follows:  
 | bytes | meaning |
 | ----- | ------- |
@@ -35,6 +37,7 @@ The header is 32 bytes long. and goes as follows:
 and then follows the message which already has a known length
 
 ## Image Sensors
+Listen in sensor_type.proto of lri-rs
 
 | Sensor | Resolutions | Output |
 | - | - | - |