Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Luts with incorrect file extensions are now correctly loaded #172

Closed

Conversation

jeremyselan
Copy link
Contributor

This was always the intent, but there was a bug in the
implementation, where were doing seekg on the filestream without clearing
potential error states beforehand.

This was always the intent, but there was a bug in the
implementation, where were doing seekg on the filestream without clearing
potential error states beforehand.
@dbr
Copy link
Contributor

dbr commented Oct 31, 2011

Change looks good and simple, although I couldn't really test as I'm not what combination of files causes the problem

Not directly related to this change, but perhaps there should be some message when the "try all the formats" fallback takes place? Something along the lines of:

Debug: Failed to load myfile.spimtx with primary spimtx format (File must contain 12 float entries)
Debug: Failed to load myfile.spimtx with spi3d format (Lut does not appear to be valid spilut format. Expected ...)
Debug: Loaded myfile.spimtx with spi1d format
Warning: Loaded myfile.spimtx with fallback format spi1d (check file extension is correct)

Mostly concerned about it being hard to discover that there's a typo somewhere. For example, a generic looking format like "MYLUT\n0 0 0\n0 0 1\n..." which accidentally misses it's header, and gets loaded by another similarly generic format with a different cube-ordering. Or, a non-standard or mistyped extension being loaded with an unexpected format

@jeremyselan
Copy link
Contributor Author

Committed in 6da3411.

Addressed you comments - failed loads are now logged (example below).

Logging for failed lut loads use the DEBUG level (so as not to make OCIO output too verbose by default). To enable, use either the API Fcn or the OCIO_LOGGING_LEVEL envvar.

env OCIO_LOGGING_LEVEL=3 ociobakelut --lut /tmp/identity.lut3d --format flame identity.3dl
[OpenColorIO INFO]: Baking flame lut
[OpenColorIO Debug]: Opening /tmp/identity.lut3d
[OpenColorIO Debug]: Failed alt format flame: Error parsing .3dl file.The maximum shaper lut value, 0, is unreasonably low. This lut is probably not a .3dl file, but instead a related format that shares a similar structure.
[OpenColorIO Debug]: Failed alt format ColorCorrectionCollection: XML Parse Error. Error document empty. (line 0, character 0)
[OpenColorIO Debug]: Failed alt format ColorCorrection: Error parsing .cc file. Does not appear to contain a valid ASC CDL XML:Error loading CDL xml. Error document empty. (line 0, character 0)
[OpenColorIO Debug]: Failed alt format cinespace: Lut doesn't seem to be a csp file, expected 'CSPLUTV100'.First line: 'SPILUT 1.0'.
[OpenColorIO Debug]: Failed alt format houdini: 'version' line not found
[OpenColorIO Debug]: Failed alt format iridas_itx: Parse error in Iridas .itx lut. Lut type (1D/3D) unspecified.
[OpenColorIO Debug]: Failed alt format iridas_cube: Malformed color triples specified in Iridas .cube lut:'SPILUT 1.0'.
[OpenColorIO Debug]: Failed alt format pandora_mga: Parse error in Pandora lut. No 3D Lut entries found.
[OpenColorIO Debug]: Failed alt format spi1d: Could not find 'Version' Tag
[OpenColorIO Debug]: Loaded alt format spi3d
[OpenColorIO INFO]: Wrote lg_to_srgb.3dl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants