Announcement

Collapse
No announcement yet.

Is it possible to place all multimattes within one file?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is it possible to place all multimattes within one file?

    Would it be possible, feasible and/or desirable to make the multimatte render element capable of storing more than 3 channels given we can save it in full float?

    If the multimatte file is stored in full float, each channel could take a range within each colour channel, ie between 0 and 1, then 1 and 2, etc... These could then be extracted cleanly within Nuke as 8-bit mattes.

    eg
    Obj ID 1 : R 0-1
    Obj ID 2 : G 0-1
    Obj ID 3 : B 0-1

    Obj ID 3 : R 1-2
    Obj ID 4 : G 1-2
    Obj ID 5 : B 1-2

    Obj ID 6 : R 2-3
    Obj ID 7 : G 2-3
    Obj ID 8 : B 2-3

    etc...etc...

    Or have I drunk too much coffee this morning
    Many Thanks
    Patrick

  • #2
    Would there be a transition along anti aliased edges though?

    Comment


    • #3
      Hm. You are loosing a digit of accuracy for each digit to the left. I got no idea how big the difference would be. Easy enough to test. Interesting idea.

      Comment


      • #4
        Now that my brain is back to cruisespeed, this sadly will not work. Anything that causes any two of the elements to be non-zero for the sample pixel (touching AA for example) will not work as you have no way to sperate the two distinct values after encoding them into ranges and adding them up. The only possible way would be defining Boolean ranges similar to integer boolean combinations in programming...more thought, but low hopes :P

        Comment


        • #5
          Originally posted by instinct View Post
          Now that my brain is back to cruisespeed, this sadly will not work. Anything that causes any two of the elements to be non-zero for the sample pixel (touching AA for example) will not work as you have no way to sperate the two distinct values after encoding them into ranges and adding them up. The only possible way would be defining Boolean ranges similar to integer boolean combinations in programming...more thought, but low hopes :P
          That's all a bit above my head, so I'll leave the debate to greater minds!

          p.
          Many Thanks
          Patrick

          Comment


          • #6
            Simply put:

            You can encode a single MMRE to a different range and decode it back to 0-1. But what do you do with more than one MMRE ? For example imagine 2 mattes that are both 0.5. One is ID1 and one is ID3 in your example. Then the first would be encoded as 0.5 and the second as 1.5. Now how to combine them? Simply add ? Then it would be 2.0 and decoded into a different MMRE instead of two MMREs. Once you combine them you have no means of finding out where it originated from.

            Regards,
            Thorsten

            Comment


            • #7
              Plus it's more of a pain in the arse to find out which colour range is for what and then assign a colour correction op to bring your selection back into the 0 - 1 range. Handier to just have a specific named matte that uses the regular shuffle imo - removes guess work.

              Comment


              • #8
                Well there could be a rather straight forward to use gizmo or custom op, but that obviously does not solve the impossiblility :P

                Comment


                • #9
                  could something like whats used for storing deep composite layers be used where you would store the matte index, the x and y pixel position and then a float luminace value? so they kind of get stored in separate z layers?

                  V Miller

                  Comment


                  • #10
                    Nope. EXR2 and a custom format will allow deep data (the latter according to vlado)

                    Comment


                    • #11
                      it is somewhat possible in present nuke version, but you need some external code to create the node to separate the float data, I recall some one once showed me but vray cannot at this point output the MME to one layer. I did that manually where I created 3 materials RGB, where R = 1, G = 2, B = 3 of float. In nuke we used some combination of clamp node (I don't remember exactly what else) but something to normalize the data back to 0-1 and got the proper result.
                      Dmitry Vinnik
                      Silhouette Images Inc.
                      ShowReel:
                      https://www.youtube.com/watch?v=qxSJlvSwAhA
                      https://www.linkedin.com/in/dmitry-v...-identity-name

                      Comment


                      • #12
                        This will not work in overlapping areas tho no? (e.g. touching objects AA)

                        Comment


                        • #13
                          Exactly - you'd still need a coverage map RPF style to know how much of each pixel belonged to each object. Deep layers could happily save everything in one multimatte element but again you'd need new operators written to correctly pull out the data. Would there be any major benefit over just using a script to automate the assignment in max and standard nuke ops?

                          Comment


                          • #14
                            If you could stuff all MMREs into a single RGBA that would give big size and performance improvements. Saving as deep will make things a lot worse. Given the demo data that ships with nuke 6.3 that is only RGBA + Z saved as deep data, i just don't think that is feasible in the kind of productions we do. I have been told that in "some big vfx company" that uses deep workflows already the layers have been stripped down to RGBAZ essentially for deep production. Because everything else just won't work performance and size wise.

                            Regards,
                            Thorsten

                            Comment

                            Working...
                            X