More
I found this on the processing discourse (processing.org/discourse/yabb_beta/YaBB.cgi?board=Exhibition;action=display;num=1213382538), and since I'm a huge fan of "The 4th Dimension" by Rybcynski and I'm a huge fan of processing, I decided to give it a try. This is what I ended up with. Does anybody know why I'm getting those strange lines pop up? I feel that they wouldn't be there unless my camera is interlaced or something. I'd like to improve the code so it can eventually accept video input at any frameRate. But if the processing.video.* isn't progressive, this technique will be useless to me. I could be wrong, but if anyone knows, some help would be great!

Credits

12 Likes

Tags

  • Marginalia Project 1 year ago
    Hey, we actually developed this code. Nice to see it moving around.
    So, we've also faced this jumpy lines issue and I don't really think it has anything to do with the video being interlaced or not. I guess processing will work with it with progressive scan either way, since the video.pixel array is all updated one frame at a time.
    What can be changed and that works some times to resolve this issue is the frameRate of the video captured right in the code. Try to put in some different values and see the result. Don't really know why, but it directly influences the apparition of these bumpy lines.
    From our experience, the most important factor of these lines is the memory. Make sure you've set processing's preferences on memory availability to your maximum. At best, you shouldn't get those lines while not recording the video.
    Let us know of code improvements. We'd like to hear about it.
    See ya
  • Vincent van Haaff 1 year ago
    Man, your code is unbelievable. It's great to see it on the discourse. With the little time I had, I tried to briefly look up the memory issues with the capture settings and the frameRate modification to fix that line issue, I found out that there's some memory issues with the java class that handles the deserializing of the quicktime data to the java component in processing. Java apparently can't handle the memory required to communicate to a video component larger than 320x240, let alone analyzing and processing it... but that's all I found out. So for now I'm going to try and see if I can restrict the effect to a certain pixel domain. Might be too hard to try until I get more free time. But thanks for the info about the camera question... and for your brilliant code! This is the best approach of slit scanning I've ever seen so far!

    Thanks!
  •  
  • Marginalia Project 1 year ago
    Hey, man. I don't really understand about all these environment and language specificities, but it seems that processing really doesn't provide all the performance needs for some realtime video projects. The friend I'm working with is transposing another code we've developed to openFrameworks C++ lib to see if it manages to give us the speed we need to our video instalation. I don't know really, but he tells me it will probably make it faster. Maybe it should also work with this project.

    Anyway, thanks again for your comment and experiments. It's really nice to see people having fun with it. That's what it's all about.
  •  
This conversation is missing your voice. Take five seconds to join Vimeo or log in.

Advertisement

1 Related collections

Albums Albums

Statistics

  •  
    plays
    likes
    comments
  • Total
    plays 539
    likes 12
    comments 3
  • Nov 12th
    plays 0
    likes 0
    comments 0
  • Nov 11th
    plays 0
    likes 0
    comments 0
  • Nov 10th
    plays 2
    likes 0
    comments 0
  • Nov 9th
    plays 0
    likes 0
    comments 0
  • Nov 8th
    plays 0
    likes 0
    comments 0
  • Nov 7th
    plays 0
    likes 0
    comments 0
  • Nov 6th
    plays 0
    likes 0
    comments 0
  • Nov 5th
    plays 0
    likes 0
    comments 0
Previous Week

Downloads

Please join Vimeo or log in to download the original file. It only takes a few seconds.