Jump to content


Photo

Asking Chad Capeland For A Favor--mono Channel Workflow


  • Please log in to reply
6 replies to this topic

#1 Kristof

Kristof

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 263 posts

Posted 07 October 2012 - 03:30 AM

Chad,

Recently I have been focusing more on incorporating mono channels in my Fu workflow. But it can be a battle.
I have been rendering to separate exrs that are mono if they can be (z-depth for instance, filters, coefficients, ambient occlusion...) but it already starts when you drag that file into Fusion--the loader automatically copies that mono channel to all the other channels. Do I disable the channels but one in the loader, and then use your colortomono fuse to make it a true mono image? Can I skip that channel loading part as there is maybe no speed gain from doing that? And I remember there were situations where the mono image turned into color again because of a node I used and I had to introduce yet another colortomono fuse to restore it again. Need to check the comp at work for more details...
Anyway, do you feel like making a demo on how to incorporate it properly? Thanks in advance.
  • Lemoroyalkeme likes this

#2 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 08 October 2012 - 11:04 AM

Yeah, complain to Eyeon about it. If you only check one out of the set or RGBA in the EXR loader, you would expect (or at least I would) that you'd get a mono channel image output. For formats where you don't get to chose the channel, then you are at the mercy of the format and how Fusion reads the header. Like there are such a thing as greyscale TIF's and TGA's, but Fusion doesn't care.

The shipping format that DOES support mono is RAW. You can load/save with it.

Any tool that creates it's output image in the same format as the input image will probably keep as mono. Most tools do, so I'd be curious as to what tool you were using did not. Heck, even Texture2D will make a greyscale OpenGL texture when the input is mono. OpenCL is a bit tricky, as support for mono when converted by Fusion (as opposed to manually) was a bit wonky, so some OpenCL tools aren't up to date with the current guidelines. Again, worth reporting.

Doing mono vs RGBA obviously saves you 75% of your memory, and that's huge and automatic, but it doesn't always save a lot on processing. Oftentimes it does, like in BilateralFilter, it's >3x faster, but in RandomWalker, it's just the tiniest bit faster, since RandomWalker works internally on greyscale.

#3 Kristof

Kristof

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 263 posts

Posted 10 October 2012 - 01:16 AM

Thanks for the in-depth reply, Chad. Much appreciated. I'm just beginning to realize the benefits and this workflow definitely deserves more attention. I'll get back to you on what tool did what to screw it up (probably it was just something I did wrong.)

And I also expected Fusion would switch to mono output checking just one channel in the loader.

The biggest hurdle we--Maya guy and myself, not the royal we :)--had to overcome had nothing to do with Fusion though. Apparently Mental Ray in Maya handles Anti-Aliasing differently when creating mono files, introducing edge artifacts when putting those mattes to use in Fu.

#4 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 10 October 2012 - 11:54 AM

So what we do sometimes is load in RGBA, then convert to mono (using whatever setting makes sense, there's 16 settings in ColorToMono currently, but I can add more if you need it), then save out as .RAW.

But yeah, if Fusion changed how the LD image was created based on the mono channel selection in the EXR options, that would be ideal.

#5 Kristof

Kristof

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 263 posts

Posted 10 October 2012 - 04:14 PM

Ah, time for me to update the fuse then. I'll have a look.

The loader code needs updating as there is a bug. Try dragging in an exr sequence by picking a random file of that sequence and remember the number. When done, copy that fresh loader node and paste in a text editor. You will see a magic start frame number entry that you can not edit from Fusion itself. Not that I know of anyway. It is the number of the file you clicked on when you dragged it in.

If you use relative paths and you end up with a variation of renders that is shorter than the one you dragged in while building that template flow, it will bite you in the ass: channel names are empty and blank image data is the result (black.) In short, a file with that hidden start frame number padding needs to be there. So relative paths will only work if your shot renders start with the same number each time, otherwise you will get faulty comps sooner or later. Be aware of this when building comps and producing renders for such an approach.

#6 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 10 October 2012 - 05:04 PM

Actually, the version on the blog might be outdated. I'll doublecheck in a bit (my main development workstation melted yesterday).

That's a odd bug, do report.

#7 Kristof

Kristof

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 263 posts

Posted 10 October 2012 - 05:39 PM

Ouch, sorry to hear about the meltdown.

Will report. Planned on doing that, but I keep forgetting to do it.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users