Announcement

Collapse
No announcement yet.

Rendering into VFB using "Overscan" settings in the render settings Overrides tab fails to save properly

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

  • Rendering into VFB using "Overscan" settings in the render settings Overrides tab fails to save properly

    The overscanned pixels render and display into the VFB, but then fail to save in the file. This is true both of the file that gets written out, and even using the "Save" button in the VFB to attempt to save out the RGB manually. Vray 5.

    EDIT: Actually, what happens is that both Nuke and After Effects interpret the image resolution incorrectly. I'm not sure if this is by design or a file encoding error. If I bring an image into Photoshop, it correctly displays the full image resolution and shows all the pixels. If bring it into AE or Nuke, it's cropped.
    Last edited by SonyBoy; 13-01-2023, 06:27 PM.

  • #2
    It's supposed to look cropped. In Nuke, however, there is a dotted line previewing the overscan (check screencap). According to this post, you can't preview it in AE.
    Attached Files
    Aleksandar Hadzhiev | chaos.com
    Chaos Support Representative | contact us

    Comment


    • #3
      Yes, although there is a preview box appears in Nuke, in After Effects there doesn't appear to be any means to interpret or preview such an image as having extra pixels at all. Furthermore, in Photoshop the image reads and displays at full resolution with all pixels visible. This all seems very unintuitive, confusing and unnecessary. What's the thinking behind this? I can't think of any reason why it's desirable to have an image be interpreted as anything except its actual native resolution, with all pixels visible by default.

      Comment


      • #4
        One thing that it is useful for is post-production motion blur - to get an adequate result in the image's edges, it's a good idea to have additional information beyond the chosen resolution.
        Aleksandar Hadzhiev | chaos.com
        Chaos Support Representative | contact us

        Comment


        • #5

          Yes, I’m aware of the reasons to render overscan (others include lens distortion or 2D post camera moves), but what I’m asking is why the extra pixels are apparently written into the file info in a different way to normal, so that the image resolution is interpreted differently by Nuke and After Effects?


          So e.g. an image that is 1000 x 1000 pixels with 10 percent overscan is actually 1100 x 1100. But it will still be interpreted as 1000 x 1000 by these two programs, with the extra 100 pixel margin hidden/cropped by default.


          I don’t understand this behavior or why it would be desirable. Although I suppose it's reasonable to assume that an image rendered with overscan is going to be ultimately used at the resolution values in the main render settings resolution fields, there are scenarios where this is NOT the case and it would seem more sensible to let the user/comper decide how a compositing program should interpret resolution. This is particularly true in After Effects, where the extra overscanned pixels are simply hidden at file import with no way to know they are even there.
          Last edited by SonyBoy; 16-01-2023, 12:21 PM.

          Comment


          • #6
            Overscan is a separate functionality written separately (in the data window). In other words, it's not simply adding pixels to the original resolution.

            Originally posted by SonyBoy View Post
            it would seem more sensible to let the user/comper decide how a compositing program should interpret resolution.​
            In Nuke, you can show the overscan through the Viewer properties ("S" key in viewport > show overscan).

            Originally posted by SonyBoy View Post
            This is particularly true in After Effects, where the extra overscanned pixels are simply hidden at file import with no way to know they are even there.​
            Sounds like an Adobe forums thread.
            Aleksandar Hadzhiev | chaos.com
            Chaos Support Representative | contact us

            Comment


            • #7
              Thanks for the reply. However, this doesn't really address what I'm getting at. I'm aware that it can be previewed in Nuke, and in AE I'm pretty sure there isn't anything you can do to get something similar -- which means if you import such images to that program and don't know they are overscanned, you'll be completely oblivious.

              In any case, my main question was what is the thinking behind how these files are written out.

              You've stated "Overscan is a separate functionality written separately (in the data window). In other words, it's not simply adding pixels to the original resolution."

              What do you mean by this, beyond the technicalities of the way the file metadata or header is written? Because for all practical purposes for the user, it IS simply adding pixels to the original resolution. So this is what I'm trying to grasp and get an understanding of why the file is written out in this way in terms of usefulness and intuitiveness for most people's workflow.

              For example, could it be something to do with keeping camera angle of view correct? That is, using overscan is adding to the angle of view in a way that would technically be incorrect for a camera of any given focal length?

              Or some other reason?
              Last edited by SonyBoy; 23-01-2023, 08:17 AM.

              Comment


              • #8
                AFAIK "Data Window" & "Display Window" are features specific and native to OpenEXR.

                Display Window would be your working resolution (1920x1080 for regular HD i.e.), while Data Window can be smaller or larger than that. I think it makes sense to have that separation, since - as you mention - padding the frame with overscan changes not only the resolution but effectively also the field-of-view.

                Perhaps there could be an option to bake the overscan into the Display Window, but the current behaviour is the correct default I'd say.

                Comment

                Working...
                X