16bit DMX fixtures and pixel drawing

[Arvol]

#2 is already do-able

phpBB [video]

[curtislx@hotmail.com]

#2 is not doable, not in the way I'm talking about.

Any update on this resolume people?
This seems to be a pretty popular request! Even just dummy channels in the middle of fixture types would work for cryin out loud.

[Arvol]

How is that video not what you're asking for?

[Jambalob]

Just want to bump this again. 16bit fixtures would be a great feature. Most of the TV/Film people use PRG Mbox or other pixel mapping programs because they can accomplish this. I've been playing around with a few media servers and see a lot of advantages using Resolume with that one exception. There are other features I would like for Advanced Output in regards to pixel mapping and fixtures, but 16bit is at the top of the list.

[curtislx@hotmail.com]

I could also really use these two features:

1- 16bit colour (being able to put dummy channels in between colours would work just fine as well.)

2- a way to control individual fixture intensity (opacity), or groups of fixtures intensity (opacity).
Even a way to enable/disable fixtures or lumiverses without having to go to the advanced output section.
Slice transform doesn't do this properly, i've tried a bunch of different ways.

I know it sounds whiny, I also love this product, but i assure you I could create and build much better with this kind of control. Merging lighting and video correctly.

I still use MA2 as well as resolume, so I'm not looking to replace my lighting console, just a nicer way of combining the two.

Thanks!

[Dagobert]

Hi Zoltan,

it would be really nice to at least add a workaround to control 16 bit fixtures with 8 bit data by adding something like a RRGGBB mode which just outputs the 8 bit values twice hence allowing a 6 channel 16 bit fixture. Real 16 bit color channels would be nicer, but this would fully suffice at least some applications.

Best regards -- Dago

[boac]

I'm new to Resolume, coming from the lighting world. I'm actually surprised Resolume can't handle 16bt parameters and pretty disappointed it's not even possible to fake it with dummy channels. The fixture editor is really very basic.

This Topic is a few years old now, as is the last reply from Team Resolume... so I guess it's not likely to happen any time soon. Shame.

[avclubvids]

we have some fixtures that have 16-bit panning, and with Resolume's current 8-bit limit on DMX, those fixtures shudder and skip around when we use Resolume to control their movement. It would be nice to have the ability to control 16-bit fixtures in Arena, as of right now we either need to drop Resolume entirely or figure out the best way to control fixture movement from a different application using DMX merging.

[kevanatkins]

Have there been any updates on on this front?

Not having 16-bit output along with the general inflexibility of the fixture profile creation is a bit of a killer for me. 8-bit really doesn't cut the mustard for high quality greyscale mapping. The inflexibility of the fixture profile creator is pretty frustrating. If I need to run fixtures in a more advanced mode for whatever reason, I don't even have the option of padding the LSB with a dummy parameter. So I have to create a fixture per pixel, with a dummy parameter next to it, then copy and paste. At the very least, we should be able to have a choice as to whether blocks of pixels within a fixture profile are contiguous or not.

For my current project, I'm probably going to have to use Millumin for the pixel mapping portion, which is real shame because, otherwise, I really like Resolume and Millumin's pixel mapping workflow is pretty jank, but I still get 16-bits to work with on the way out and custom gamma curves... 8-bit DMX renders features like the colour and gamma correction features pretty useless in practice. Any positive gamma adjustment results in pretty nasty downsampling, which can be a real problem when trying to make fixtures from different vendors place nice together or be able to work in high dynamic ranges. For instance, at the default gamma value of 2.5. The last 11% of the brightness range is represented by the 1 bit of resolution. The last 18% is only 2 bits of resolution. Now obviously that's an extreme example. But even a more reasonable gamma value like 1.5 is still only 2 bits of resolution in the last 6% of the brightness range and 4 bits of resolution in the last 15% of the dimming range. It's not a problem with high contrast, high saturation content on RGB tape, but any high dynamic range content is going to struggle with banding/stepping in the low end of the brightness range, which is a real shame...