Fri, Sep 17
Mon, Sep 6
Fri, Sep 3
Mon, Aug 30
Think I wont have time for this, will step down since there is another patch around.
Aug 16 2021
@Sergey Sharybin (sergey) The one in the linked report should do it - on Windows at least. Pasted here as well:
Think it would be nice to have an offending image, so that we can start building a regression test collection. Can you attach a file which showcases the memory access issues?
A similar issue is happening in this video: https://youtu.be/kxgH2whhc8g?t=41
Aug 6 2021
Aug 4 2021
Small tweaks, no functional changes expected from previous commit
- Make an earlier check against mem_eof. It was already checked later but it wasn't as obvious.
- Leave a note about one last problem that remains unsolved
Aug 3 2021
Jul 20 2021
The current heuristic works well for Blender in many cases because the standard channel and pass names do not contain dots. The view layer name on the other hand is more likely to have dots, and is parsed correctly if you go from right to left. So I think that's pretty reasonable.
it would break again if the view layer has dots in it. Maybe the safest option is to enforce no dots in the aov and view layer names. Can't believe exr stores variables in the string, I thought it would use something like exr or json.
although the above alternative method I posted of getting the tokens from the string would also enable a user to import from other softwares that have dots in the pass name.
other software doesn't matter, the files generated will only ever be used by Blender.
Would it be possible to keep everything as it is, but just use the code I posted above, then it won't matter if there are dots in the pass name, and it'll continue to work under all circumstances it currently works for. In the case of there being only two tokens, then you could just have:
First, I would recommend to not use dots in the names at all, as they are the standard separator for EXR and it will inevitably lead to problems in Blender or other software. On top of that, while the EXR specification mentions dots, a lot of other software deviates from that and uses underscores instead. So I would use neither.
nope, still breaks if the pass has dots in it because the function that creates the image blocks when opening EXR's is searching from the right of the string, splitting it to get the channel, then searching from the right again and splitting it to get the pass, and then one more time to get the layer.
I can just manually add something without dots to the beginning of the input name for now. Would be great to have the file output node do that automatically though.
yes, it should definitely follow the same convention as the rest of blender:
so if the file output node isn't going to let the user specify a layer to assign the inputs to, then it should just add 'Combined' between the name and the file_format.
OK, I found the problem. It's the file output node not adding any layer to the name:
Problem seems to be the assumption in imb_exr_split_channel_name / imb_exr_split_token that the whole name contains three tokens:
i'm outputting the file from the compositor file output node by the way, whereas you're outputting it from a render animation.
hmm, in your file it doesn't show an output per layer, instead it changes the outputs based on the chosen layer. The functionality that my addon relies on, is to show all layers as outputs, otherwise it'll break a couple of months worth of programming.
Hm, here is a similar file that actually seems to work:
Probably not a duplicate, I guess that indicates Nuke also has the same bug....maybe they're both using the same function of the openexr library to import, whereas Affinity isn't?
T71574: OpenEXR layers from View Layers with names containing a period can't be read by Nuke is related (if not a duplicate)
Jul 18 2021
Improve comment, add asserts
Jul 17 2021
Jul 16 2021
A different fix was committed.
Jul 15 2021
Jul 9 2021
Yes, most software allows placeholders to be used inside a filename detailing where the udim information can be extracted from. Some examples are supported by OpenImageIO directly: https://openimageio.readthedocs.io/en/master/texturesys.html#udim-and-texture-atlases
I just saw how Pixar addresses the different naming conventions in Renderman. It's actually better than Maya.
Will confirm as it is failing in blender's own parsing code: