• State Verified Answer
  • Date
    davidayton
  • Date
  • Replies 2 replies
  • Subscribers 188 subscribers
  • Views 806 views
  • Users 0 members are here

Pixel Mapping - stretched pixels bug?

Hello

I’ve come across unexpected behaviour when using pixels that have been stretched to cover more than one square on the pixel map grid.

Firstly, content isn’t respecting the stretched cells - if you look at the attached video, looking at pixel map preview with the cells overlay -  the white line is the content, but the fixtures only activate when the most central pixel square gets content, not when the content reaches the fixture as laid out in the pixel map.

Secondly, when selecting a stretched pixel to re-number it, every square of the stretched pixel gets broken down and given a new subsequent channel number, rather than it treating the stretched pixel as one channel. 

I suspected this may be an issue using multi-cell fixtures as that’s what it’s affecting here, however I can confirm consistent behaviour when using whole channel numbers and not just multi-cell fixtures.

Running Eos 3.0.1 Build 31.

Thanks,

David

  • 0

    Hello,

    This is still the case having updated to v 3.0.2 Build 6.

    My initial thinking was that this must be a bug - otherwise what's the point in being able to stretch a pixel over multiple grid squares in the first place? However maybe this is expected behaviour - this is my first time stretching a pixel to cover more than one square, so I have no comparison point.

    In the video (not sure if it's uploaded as it still says preparing video) the fixture is behind me and you can see the reflection on the monitor when the content activates the cell on the pixel map, and not when the stretched area receives the content.

    Thoughts welcome on this - would be good to know if this is expected behaviour if there is a workaround?

    Thanks,

    David

  • +1

    We chatted about this off the forum as well.  This is currently working as expected for v2.x and v3.0.x. The Pixel Mapping feature was built long before the concept of multicell was introduced to Eos software.  If you add a multicell to a pixel map along that stretched pixel, it'll behave as you expect, but with a single channel, it keys off the center "dot" of the pixel.  It's not built to, say, average the brightness and color of content across that stretched pixel. 

    We will probably improve that in the future, but have no timeline at this point to do so.

Related

www.etcconnect.com