Layered exr + animation error



  • Hello,
    I am testing Altus for animation and I cant seem to make it work
    my render a and be are called img01_0000.exr and img02_0000.exr
    here is my config file:

    out-path=C:/Users/me/render_altus/altus_animation_test_%04d.exr
    rgb-0=C:/Users/me/img01_%04d.exr::#0005#Beauty
    rgb-1=C:/Users/me/img02_%04d.exr::#0005#Beauty
    pos-0=C:/Users/me/img01_%04d.exr::#0002#Position
    pos-1=C:/Users/me/img02_%04d.exr::#0002#Position

    and here is the error:
    [ FATAL ] Runtime error: Cannot read image file "C:/Users/me/img01_%04d.exr". No such file or directory.
    I first tried in the GUI and then in command lines. and errors are the same.

    is it possible that layered exr + animation wont work?

    thanks.


  • administrators

    Hello!

    Layered EXR and animation definitely work! But as you've noticed, configuring it can be tricky.

    I'm assuming layer "0005" and layer "0002" are your beauty and position passes, respectively.

    Missing from your configuration file are the start and end frame numbers — without these specified, Altus won't go into animation mode. If your start frame is "0001" and end frame is "0100", e.g. you have files on disk:

    img01_0001.exr
    img02_0001.exr
    img01_0002.exr
    img02_0001.exr
    ...
    img01_0099.exr
    img02_0099.exr
    img01_0100.exr
    img02_0100.exr

    You'll want to pass Altus the options (through the CLI or config file):

    start-frame=0001
    end-frame=0100

    Please note, the padding of zeroes in start-frame and end-name is significant!

    Let me know if this works!

    Regards,
    Samat



  • I also had ton of issues with that and after couple hours of testing it figured that having 0 infront of number ie padding like 4.. 0300 or something creates issues.
    Instead what seems to be working is using %01d and using no padding at all. starting with 1,2,3.. 34,35...123,124. and so on.. so far padding seems to be hell of usage.
    I'm honestly wondering why using such non standard padding at all and simply using #### where number of #marks padding as well?
    That is kinda standard and mostly used for rendering frames at first place?

    This testing seems to work on 1.8.1, on 1.8.2 it can;t even find file if #### is used as frame number wildcard.

    Oh btw once cfg is saved with animation option and frame padding setup, if you load it later int gui it messes up things and instead of %01d.exr it changes that to something like %%%%00dddd.exr

    Also you can;t put 0001 in UI because it removes front 0 right away so putting there and then editing cfg would be needed as it seems?

    edit:
    couple more hours testing and figured taht version 1.8.1 kinda properly reads %01d and maybe even other wildcards.
    version 1.8.2 is messed up on that side and can;t read padding at all.

    @msh try something like:
    rgb-0=C:/Users/me/img01_%04d.exr::#0005#Beauty

    and if that is not working you can try also something like
    rgb-0=C:/Users/me/img01_%01d.exr::#0005#Beauty
    but also rename all frames not to have any padding eai to go 1,2,3..45,46.. .etc.


  • administrators

    Looking into this, we found a bug in 1.8.1/1.8.2… do you guys have access to 1.7 or 1.8.0 and mind checking with that? I've made the 1.7.1 download available again at https://www.innobright.com/downloads/.

    We're probably going to release 1.8.3 later this week with a quick fixes for this.


  • administrators

    Hey everyone,

    We've released 1.8.3 that should contain fixes for problems with animations. Please let us know if it fixes your problems!

    https://www.innobright.com/downloads/



  • Hello,

    Trying 1.8.3 here, with animation + layers.

    My sequence is like this :
    RGB_B0.#####.exr, going from RGB_B0.00051.exr to RGB_B0.00100.exr.

    Adding path is a nightmare :
    RGB_B0.00051.exr is changed to RGB_B0.%03d.exr ( should be RGB_B0.%05d.exr)
    Adding other AOV path changed field from previous input Oo

    alt text

    So after adding all the path, RGB AOV path looks like :
    RGB_B0.%%%%%00ddddd.exr

    Altus result seems awsome, but guys, I think it takes me more time to fight with the AltusGUI to encoded the path than computing the denoise.


Log in to reply
 

Looks like your connection to Innobright Forums was lost, please wait while we try to reconnect.