More flexible image data format for updating

[JiayinCao]

Hi,

This is not a necessary feature, though, it would be a lot more helpful to have it.

Basically, the way to update multiple channels together is to do it the way similar we update one single channel. The difference here is to send three channels of data together, instead of just one. This does eliminate the possibility of partially updating one single channel before refreshing the image viewer, which was the purpose.

However, the way it requires the data to be packed is a bit inefficient. Since lots of application commonly saves data in the form of interleaved data, like this

• [ R, G, B, A, R, G, B, A, R, G, B, A ]

While tev requires this form

• [ [R,R,R], [G,G,G], [B,B,B], [A,A,A] ]

This means that for an app with the above internal memory layout, it has to create a temporary memory to hold the data in the format tev wants and also an extra memory copy because of tev.

It would be nice to support the above format too. A solution to support this is fairly simple, tev can ask for per-channel metadata, that should have 'stride' and 'base_offset'

• stride, the memory size in terms of bytes between each channel value of the pixels
• base_offset, the start address of the memory for this channel.

With the two, we can actually support both the two layouts in a unified implementation and there is definitely flexibility to support more memory layout with this change.

• [ R, G, B, A, R, G, B, A, R, G, B, A ] Channel meta data would be, ['R', 0, 16], ['G', 4, 16], ['B', 8, 16], ['A', 12, 16]
• [ R, R, R, G, G, G, B, B, B, A, A, A ] Channel meta data would be, ['R', 0, 4], ['G', 12, 4], ['B', 24, 4], [A, 36, 4]

This way, applications, like ray tracer, don't need to create a separate memory just for holding data to pass to tev and also saves the cost of memory copying from its own memory layout to tev requested memory layout

Thanks

[Tom94]

Heya,

I was a little on the fence with this one as this is a slippery slope. Wanting to support direct transfer of frame buffers could easily evolve into also requesting multiple precisions, image formats, pre-multiplied alpha or not, etc.

Basically, implementing a whole 'nother image format.

And the performance/memory benefit is only really there when the renderer runs on a different machine from tev. If it's the same machine, the conversion to tev's internal non-interleaved format needs to happen somewhere on the system anyway.

But I guess this is simple enough to just hack in for now---plus a fun little exercise in making my ghetto IPC protocol backwards compatible after the fact. :p