Page MenuHome

Cycles: Autodetect if a RGB texture is actually BW (all 3 channels equal).
AbandonedPublic

Authored by Thomas Dinges (dingto) on May 12 2016, 3:39 PM.

Details

Reviewers
None
Group Reviewers
Cycles
Summary

This way we can use a single channel slot and save memory, and the artist doesn't need to worry about saving the texture properly.
Main question is, do we want this? What about startup performance?

Note: Only implemented for OIIO (textures from disk) atm, no packed ones.

Diff Detail

Repository
rB Blender
Branch
cycles_detect_channels

Event Timeline

Thomas Dinges (dingto) retitled this revision from to Cycles: Autodetect if a RGB texture is actually BW (all 3 channels equal)..
Thomas Dinges (dingto) added a reviewer: Cycles.
Thomas Dinges (dingto) updated this object.
  • Fix for reading byte textures.

How much often this actually happens in practice? In my experience i don't recall running into cases like this.

The issues here are:

  • You do full image load and traversal in from within add_image() which is actually supposed to be more O(1) complexity and don't do any heavy thing.
  • That leads to a much slower nodes generation
  • You're reading image twice, which is also not good

So for me currently it looks more a no-go.

As discussed in IRC, we can make this a UI option and don't read texture twice. User would set a "IS_BW" (or whatever) flag in the UI, then we only read the one channel, no need to autodetect then.

Eh.. That's not the UI i was talking about.

The UI i had in mind was related on the memory manager project you're working on, where you can detect such cases and inform people that they can save memory and disk space by re-saving particular file.

I don't mind if it's done automatically, but not with the current approach where you're slowing things down to achieve bit of memory gain in certain circumstances only.

Ah I understand, sorry for the confusion. :)

I think I mentioned this to DingTo in IRC, but if we're eventually going to be running all textures through MakeTx or our own pre-chewing utility, it can do this while building the mipmapped version.

I wouldn't rely on MakeTx too much, it's still important to keep ImBuf backend same feature-complete, which would be tricky with maketx. And there's no huge advantages on relying on OIIO more and more, especially when we know all the features we need are also to be implemented for ImBuf.

Regarding performance:
I just did a quick test, even the most basic for(int i = 0; i < num; i++, data += 4) if(UNLIKELY(data[0] != data[1] || data[0] != data[2])) return false; runs in 0.2sec for a 16k texture.
So, I guess the main problem here is that by the time the image is in memory and can be checked, the slot has already been allocated and the type can't be changed anymore.
However, if I understand the bindless texture system correctly, one of the side effects would be to get rid of the slot system - that way, automatic monochrome detection would work pretty well I guess.

It's not an issue in performance of checking the textures for amount of channels, it is a performance of compiling shaders. With this patch single-threaded nature of shaders compilation will slow image load down. It causes image to be loaded at a moment they were not supposed to -- we deliberately load images after BVH construction to reduce memory peak.

In the current state the patch is not acceptable.


In a longer perspective, such things is more up a business of scene investigation tools, which will detect such cases and suggest user to re-save image in a single channel format.