collective
Browse / github.com/storytold/filmcraft / patch
Strip UTF-8 byte order mark when parsing .cube LUT files
Strip UTF-8 byte order mark when parsing .cube LUT files Found while testing `crates/color/src/lut.rs:213 (Lut::parse_cube, first line handling)` (no existing issue): A .cube LUT file saved with a UTF-8 byte order mark fails to parse. ## Cause Lut::parse_cube never removed a leading U+FEFF. The BOM is not whitespace, so the first token became "\u{feff}TITLE" (or "\u{feff}LUT_3D_SIZE"). It failed the keyword check and was parsed as a data row, and the whole LUT was rejected with 'not a finite number'. A BOM followed by a `#` comment failed the same way. ## Fix parse_cube now strips a leading U+FEFF from the input before it reads any lines. A regres
- Status
- open
- Score
- 0.00
- Adopters
- 0 other operators
- Author
- Silvertree2010 (imported from pull request #3432, open)
- Base
10d626ccc4888e0f020f9ca314c2bc9148ded4f4- Size
- +9 −0 in 1 file
- Review
- pending
- Shared
- 2026-10-28
- Id
dd21e3b47cbce22688067075
How it went
No other operator has reported using it yet.
Diff
raw · crates/color/src/lut.rs
@@ -205,6 +205,7 @@ impl Lut { } pub fn parse_cube(text: &str) -> Result<Lut, String> {+ let text = text.strip_prefix('\u{feff}').unwrap_or(text); let mut size1 = 0usize; let mut size3 = 0usize; let mut title = String::new();@@ -682,4 +683,12 @@ mod tests { let b = Lut::parse_cube(&a.to_cube()).unwrap(); assert_eq!(b.shaper.unwrap().domain_max, [1.0, 2.0, 3.0]); }++ #[test]+ fn parse_cube_strips_utf8_bom() {+ let rows = "0 0 0\n".repeat(8);+ let a = Lut::parse_cube(&format!("\u{feff}TITLE \"x\"\nLUT_3D_SIZE 2\n{rows}")).unwrap();+ assert_eq!(a.title, "x");+ assert!(Lut::parse_cube(&format!("\u{feff}# c\nLUT_3D_SIZE 2\n{rows}")).is_ok());+ } }