docs: WIP "Config Syntax" docs #296
Conversation
…her minor improvements: - Ref links on a few sections mentioned by the config-syntax docs - Terminology explains "Look", expanded on role description slightly - Main text has margin on right to prevent squishing up against side of browser - Expanded ociocheck description, with examples of problems it catches - Doc building ignores weird emacs-temp-file created for unsaved files, because they get copied and break Sphinx, but are never cleaned up on subsequent CMake runs.
|
What's written so far looks great. Keep it up! :) The intent of strictparsing was so the configuration can hint whether, if a colorspace name cannot be parsed, whether to fall back to the default or not. The best example of this is when $OCIO is not specified, strictparsing=false and the default color space is raw. This means that ANY string passed to OCIO will be parsed as 'raw'. This is nice because if you do not specify OCIO, the behavior from an external app's perspective is that the library essentially falls back to 'un-color managed'. Note NOT to be included in the docs... In the long term this will likely be super-ceded by a more granular mechanism that will programmatically help determine the color space from format, metadata, filename, extension, etc. The luma coefficients are not used anywhere inside OCIO. That is a legacy configuration option from the closed-source predecessor to OCIO, and it turned out to not be helpful. In a future version it should be deprecated. No apps, to the best of my knowledge, pay attention to it. |
- Looks section explained - Change heading syntax - Further explaination of `strictparsing:` - Mentioning potential upcoming deprecation of `luma:` setting
Smallest heading was 1.0em which appeared same-or-smaller than the 0.9em body-text. Increased size of all heading levels to something more subtantial, which makes the structure of the documentation clearer
|
Updated docs with newly acquired knowledge of luma and strictparsing, and added looks section. Just Also included Fedora install instructions as @hobbes1069 reminded on ocio-dev, and same with the Homebrew formula (which I just realised has ticket #252 ) |
|
Is this ready for consideration yet? :) |
|
it looks good to me... |
Level 1 heading =============== Level 2 heading *************** Level 3 heading +++++++++++++++ Level 4 heading ---------------
Also fix labels on installation docs
|
Not quite - almost done the description of Should be finished tomorrow! |
|
Ready to merge, as long as there's no horribly misleading and confusing errors in the new docs! The transform section needs a bit more work (mainly copy-and-pastable examples of things like the Summary of the changes:
|
|
Looks good to me. Committed in 2268a5b |
3 participants
Don't merge this yet, as its incomplete.. Pull-requesting to supersede the #294, so any discussion doesn't get spread out
I've started documenting the config format, in a "what do each of these values do?" kind of way.
Everything interesting is in the
config_syntax.rstfile. Should be pretty readable in raw form, but I'll update my gh-pages branch later, if I remember..There's a few bits I had to guess what they do by prodding around in the code, as I'd never really used them.
@jeremyselan Can you confirm what's written so far is in keeping with the original intent of each option?
Particularly, I kind of guessed about the following (from memory and grep'ing around the code):
strictparsinglumaare used (like, it doesn't impact the CDLTransform)Also I couldn't think of a more concise description of the
ocio_profile_versionandroles