Smal Pixel mapping

is there in the next update a pixel mapping or what are the plans?
it will be useful even if you have only 20 sunstrips or led fixtures
the video you do with a media server but for those little things very handy:)
  • I think it is a much needed feature as well.
    As far as I understand it, the new H4 desks have so much overhead in their processor that the desks could easily handle this.

    There are some distinct advantages to pixel-mapping directly off the desk.
    For instance if I want to play back media across an array of fixtures and then suddenly have all or even just some of them go to a solid color....it requires additional layers on the media server, potentially with custom masks, transparencies and/or alpha channels.
    With direct control off the desk I could have all the fixtures "playing back" a video clip and then use the outside fixtures in a solid color to frame it for example all very quickly and easily without having to resort to tricks off a media server or a DMX merge between a server and a desk.
    It makes it much cleaner and quicker to just do it all off the desk.

    I know it is a feature that has been discussed and is planned, just no idea when they will actually be able to implement it.

    Hope this helps. :)
  • As per the specs on the HES website, the H4 is on an Intel I5, the FB on an Intel I3, both I believe are Dual Core, not quads. I have two Arkaos MMP servers that are running overclocked dedicated I7 quads with matched Boards, 16gigs of fast ram and a top of the line AMD firepro card and I have no problem choking those machines if I try, especially when I'm sending to a pixelmap instead of just a video surface . Sure, the H4 will never be a replacement for a Media Server, but I don't think you realize the amount of processing at the CPU, that's required to simply decode a compressed video file and then convert it to DMX data for a mapped surface. Sure, the H4 could do it, but either way you look at it, your gonna be taking from peter to pay paul and the control response from the desk is gonna suffer. It may be unnoticeable, or completely noticeable. In the end, unless your running a very low resolution Pixelmapped Effect, your gonna end up using a media server anyway.

    Doing an LTP, HTP or switchable Artnet or DMX merger at a node, IMHO, is actually as easy and intuitive as it would be if you were running the media and a fixture patch out of the console.

    Pixelmapping from the desk is indeed a cool feature, but if it gets in the way of the control desk doing it's primary job, then it's more of a hindrance.

    Another thing to consider... The use of LED's as a image display device is becoming more popular and more affordable. The displays are getting bigger and of smaller pitch, which basically means more pixels overall. The big LED rigs of yesterday will be the small rigs of tomorrow.

    With that being said, if HES does implement a video driven pixel mapper on the H4 without sacrifice, then better still.

    JB
  • [QUOTE=Buzz313th;73200]As per the specs on the HES website, the H4 is on an Intel I5, the FB on an Intel I3, both I believe are Dual Core, not quads.

    Where do you see this info? I could not find it. As far as I know the H4, FB4, & RH4 all use the same AMD processor. Slightly different motherboards between the models, but the same processor on all of them, but maybe I am thinking of the onboard DP-8000 processor on all of them.

    [QUOTE=Buzz313th;73200]I have two Arkaos MMP servers that are running overclocked dedicated I7 quads with matched Boards, 16gigs of fast ram and a top of the line AMD firepro card and I have no problem choking those machines if I try, especially when I'm sending to a pixelmap instead of just a video surface . Sure, the H4 will never be a replacement for a Media Server, but I don't think you realize the amount of processing at the CPU, that's required to simply decode a compressed video file and then convert it to DMX data for a mapped surface. Sure, the H4 could do it, but either way you look at it, your gonna be taking from peter to pay paul and the control response from the desk is gonna suffer. It may be unnoticeable, or completely noticeable. In the end, unless your running a very low resolution Pixelmapped Effect, your gonna end up using a media server anyway.

    Arkaos isn't really any kind of an accurate benchmark for anything Hog related.....apples to oranges....if you want to go that way I have run Ivy Bridge i7 AXON servers with 9 layers of full HD (1920x1080p) and all 32 FX running crossfades as well as visual FX running crossfades, etc.....the CPU never got above 30% or so...GFX and HDD were all performing well this way too....in short the severs were not even breathing hard....a Windows or Mac computer is burdened with all kinds of things a dedicated OS system like Hog or AXON doesn't have to worry about. Will it take system resources to run video files? Of course it will, but with the current hardware being what it is I highly doubt we would see any noticeable lag in performance.

    I do agree that any type of truly "heavy duty" pixel mapping should be done via media server or dedicated product interface/processor.

    [QUOTE=Buzz313th;73200]Doing an LTP, HTP or switchable Artnet or DMX merger at a node, IMHO, is actually as easy and intuitive as it would be if you were running the media and a fixture patch out of the console.

    I disagree with you there too. More pieces of gear in the system mean more potential points of failure. It would be far more elegant and streamlined to have all of this contained within the desk via software.

    [QUOTE=Buzz313th;73200]Pixelmapping from the desk is indeed a cool feature, but if it gets in the way of the control desk doing it's primary job, then it's more of a hindrance.

    Agreed, but as I stated above I highly doubt this will be an issue given the current hardware spec on the desks.

    Hope this helps. :)
  • Hey Marty, Processor info on 1st page under Hardware.

    H4.. www.highend.com/pdfs/HOG_4_Console_ArchSpec.pdf

    FB4.. www.highend.com/pdfs/Full_Boar_4_Console_ArchSpec.pdf

    RH4.. www.highend.com/pdfs/Road_Hog_4_Console_ArchSpec.pdf


    As for the onboard DP8000... Correct me if I am wrong, but I do believe they are sharing the one and only processor on the desk. As far as I know, or assume, the onboard DP's don't have their own CPU like the external DP's do. But I really don't know, as I can't find any confirmation documented anywhere.


    In regards to the Arkaos Vs Axon..
    Take your Axon and try scratching the H264 Content. Anything not playing back forewords and your gonna peg your processor. Feed it 32bit apple pro res files and try running just 4 1080P layers. You will probably see skipping and dropped frames. Most media servers require a certain list of file types and encoding or media compression. This was done so the manufacturer can control the types of files that you are allowed to play back based on what they designed their system to do. This means that sometimes you have to re-render content to make it compatible. Arkaos is one of the exceptions, as it will take almost any file type and compression. Its up to you as the programmer to choose the best file type for the type of playback you intend on using.

    I can run 12 layers, with piled on realtime rendering effects, on 6 outputs of 1080P foreword compressed with H264 no problem.. But as soon as I try to run one H264 layer on one output backwards or scratch the content then I choke the system and it pegs the processor at 100% load. Or if I take 3 simple files 30 seconds long encoded with Apple Pro Rez at 32bit color and try and run just 4 layers regardless of output count it chokes the system. It's not just layer count, output count, or what realtime rendering your doing, since that's all being processed at the GPU... it has mostly to do with how much decoding the CPU has to do and how you intend on playing it back. It's the decoding of a compressed file that will hammer the CPU. My Arkaos Boxes are dedicated for just media work, the Bios have been tweaked, the OS has been tweaked and the only processes running are the only processes needed for the dedicated media work. It's as good if not better than your Axon or the Arkaos dedicated stadium server. Don't kid yourself, most if not all the media servers are running a stripped down version of Win or Mac OS, WITH ONLY THE NECESSARY PROCESSES RUNNING. The media server manufacturers offer the servers up as turn key solutions for someone who doesn't want to do their own system configuration. Its still nothing more than a Windows or Mac box running software. But more importantly, it's a separate system, designed specifically for manipulating and outputting media in realtime. Personally, I would like to see the Hog play to its strong points and not get labeled as a "Jack of all trades and a winner of none".

    It's a good forum here and no reason to agree, if you disagree, so I respect your opinions.. Sure, more gear means more points of failure... But I don't feel comfortable adding extra load and tasks to the most important piece of hardware in the system...which is the control desk. Especially when I can use a dedicated media server.

    Good conversation... All very valid points.

    JB
  • I see the point above but if a Chamsys can handle basic Pixel mapping saying a Hog can't, we may as well go home now.
    Not to mention Avo, Ma and several others......
    Its a basic tool that a lot of people expect if we don't have any form of it then it takes us out the running. just my two cents.
  • I'm not saying a Hog can't handle it. I guess what I'm saying, is that IMHO, Pixelmapping and running media from a console will always have its limitations when compared to a dedicated media server. So why bother doing it half assed. Just get the correct tool for the job.

    You bid a job with just a desk telling the client you can send the LEDs a media file. Then the client sees what you can do with a small array of pixels and wants and asks for more. If your at the limit of your bitmap fx from the desk, then what?
  • If you can afford a media server that's great but not every job can or if all your controlling is 10 led battens hung from a rig grouped into a 10x10 pixel square and you want to run a small effect across them, its a pain, whereas with even Avo (and i hate saying that) its really easy to get something running on it (and I'm talking a star or something that the effect engine can't do) (and doesn't get into media server world)
    Do we know what the limits of pixel mapping is on things like Avo and chamsys?
    If Hog could do everything Chamsys does and more (like we are pushing into) then every chamsys user, would naturally progress onto the better feature set of Hog.
  • I think the main problem here is what is meant by each of us when we say "Pixel-Mapping"
    Thats why I was asking in which situations and which kind of arrays we are tlaking about.
    a 10x10 LED Battens is something small.
    But the problem is what JB mentioned: the limits.
    I dont know how AVO or MA or Chamsys handles this. From GMA1 I know that had only small bitmaps. LSC Clarity can play movies...
    I think what most people want to see is an easy bitmap animator. And not a an option to playback Full HD Videos. Together with that an more advanced selection tool like MATricks.
  • Avo: www.avolites.com/news/details/articleid/414/the-power-of-avolites-titan

    Chamsys: www.chamsys.co.uk/magicq_pixelmapp

    I dont expect full HD video content, personally.
  • [QUOTE=Buzz313th;73203]Hey Marty, Processor info on 1st page under Hardware.

    H4.. www.highend.com/pdfs/HOG_4_Console_ArchSpec.pdf

    FB4.. www.highend.com/pdfs/Full_Boar_4_Console_ArchSpec.pdf

    RH4.. www.highend.com/pdfs/Road_Hog_4_Console_ArchSpec.pdf


    Cool....didn't even think to look there,

    [QUOTE=Buzz313th;73203]
    Take your Axon and try scratching the H264 Content. Anything not playing back forewords and your gonna peg your processor. Feed it 32bit apple pro res files and try running just 4 1080P layers. You will probably see skipping and dropped frames.

    Yes scrubbing through frames does make it work a bit harder, but not excessively....probably b/c AXON uses only VERY SPECIFICALLY encoded MPEG-2 content files.....H264 and Apple Pro Res, etc won't work with AXON.

    [QUOTE=Buzz313th;73203]
    Most media servers require a certain list of file types and encoding or media compression. This was done so the manufacturer can control the types of files that you are allowed to play back based on what they designed their system to do. This means that sometimes you have to re-render content to make it compatible. Arkaos is one of the exceptions, as it will take almost any file type and compression. Its up to you as the programmer to choose the best file type for the type of playback you intend on using.

    Much like Hog....I'm sure once pixel mapping is enabled, then the video file type will need to be very closely controlled in order to keep system resources from being overly taxed. I would hope/expect some type of import file screening and conversion to be available directly on the desk to help facilitate that. Perhaps there should also be a "meter" of some sort that shows us exactly how hard the system is working so we can make informed decisions as we program as to how far we are willing to push it.

    [QUOTE=Buzz313th;73203]My Arkaos Boxes are dedicated for just media work, the Bios have been tweaked, the OS has been tweaked and the only processes running are the only processes needed for the dedicated media work. It's as good if not better than your Axon or the Arkaos dedicated stadium server. Don't kid yourself, most if not all the media servers are running a stripped down version of Win or Mac OS, WITH ONLY THE NECESSARY PROCESSES RUNNING. The media server manufacturers offer the servers up as turn key solutions for someone who doesn't want to do their own system configuration. Its still nothing more than a Windows or Mac box running software.

    That is all well and good, but unless you are developing your own version of say XPe or Win7 embedded....the "standard" OS can only be ratcheted back so far....not nearly as far as a custom embedded OS verision

    [QUOTE=Buzz313th;73203].....a separate system, designed specifically for manipulating and outputting media in realtime. Personally, I would like to see the Hog play to its strong points and not get labeled as a "Jack of all trades and a winner of none".

    And for "heavy duty" or large scale use I would agree a server is a much better option. I also agree that when it is done it has to be done right, and not just as a gimmick or marketing ploy.

    [QUOTE=Buzz313th;73203]It's a good forum here and no reason to agree, if you disagree, so I respect your opinions.. Sure, more gear means more points of failure... But I don't feel comfortable adding extra load and tasks to the most important piece of hardware in the system...which is the control desk. Especially when I can use a dedicated media server.

    Good conversation... All very valid points.

    I agree. I enjoy these discussions with other intelligent people here regardless of their point of view....one of the many reasons you won't find me on some of the other forums where people just want to take a piss on one another all day long....I've got no time for that.