How to get a .txt or .xml file listing the pixel RGB values of any given video
Hello,
I'd like to learn how to make a patch where I can input a video file Jitter can read and have its output RGB values listed in a text file ready for consumption by another program not looking for video, but ready to take the values as they come...
So the text file might look like this:
102, 45, 56
107, 50, 60
and so on ...
each line being one pixel ... I guess starting from the top left and working to the right until the line/row is complete then going to the far left of the next row down (like a progressive CMOS sensor). For instance with a 100x100 spatial res on the 10,001th line you'd be inputting the top left pixel of the 2nd frame and so on...
There would be verticalRes*horizontalRes*frameNumber lines of comma delimited RGB values
I'm not a programmer (yet) - so any tips on the best way to make data easier for other programs to digest would be appreciated... maybe the lot could be simply be comma delimited rather than line and comma delimited ? (although this makes it easier for *me* to get my head around the data)
It is in its essence I guess just video data stored in a very clunky uncompressed fashion. But going about it this way means less work on the input side of the other program in teaching it (and myself) how to read movie files.
Any help appreciated
This is a start, it only does a single frame but could be modified. It's locked to 320 x 240 resolution, but you can change that too. For a single frame, writing to a [text] object, it takes my computer about 2 seconds, and the [text] window is a bit slow to load, but hey, that's 76800 lines... so we can give it a break :)
Commas are a little funky in Max, so I used tabs to separate the values instead. Probably any other program you use for the data, if it takes comma-separated values, you could use tab-separated ones instead. If you do need the comma, generally you have to use the escape character before them, so in the [triggers] at the bottom, you'd have
t , i
which sends the int value (R G or B), then a comma. However, I got extra spaces in the text file when I tried this, so I went with tab instead. Also I dropped all the alpha values.
The text file, after I saved it, was 1.2 MB for a 320x240 frame. So yes, it's big, but it would also .zip quite well I imagine.
I'm sure there are better ways to do this, maybe a way to use jit.matrixset somehow, which would be a lot faster. But this works, and demonstrates some fun objects like [uzi] and of course, jit.matrix...
also take a look at jit.iter, jit.spill, jit.textfile and the jit.str.* objects.
Hi,
firstly seejayjames - ok, I see what is happening there although I dont get how jit.matrix or jit.qt.movie work to be able to change it to do frame by frame - I was hoping the 'getcell' input to jit.matrix would simply work by adding another 'position' input (col, row, *frame*), maybe it does, but I cant figure out how ? If it did in a similar fashion I'd add another uzi into the pack and so on ...
Either that or simply do one frames worth of action then moving through time (+1 frame), starting the process again but just appending onto the text file - I dunno some sort of modulo maybe on x*y = 16 mod 16 = 0 means advance one frame - or maybe with the text query = 26 mod 26 or ???
By the way just for testing at this stage I am working with 5 frames of 5x5 res images (125 pixels total) running at 5fps (200ms period) - attached if it is of interest
But how do you get jit.qt.movie to move forward one frame only ? This doesn't need to be real time, maybe that is causing the issue ?
robtherich
I played around with jit.iter and got it to output a frames worth of pixels tab delimited (alpha incl. which shouldn't be an issue) but there were no line breaks per pixel - I used the 'done' output of jit.iter right outlet so I could at least see the end of the frame in the output (but I guess this isn't necessary for the final version).
Again, I dont know how jit.qt.movie or jit.matrix work (or anything really!) - I thought it would be simple but how can I get jit.qt.movie to just move forward one frame then send a bang to jit.matrix to do the text output ? I thought as the right output of jit.iter was sending 'done' when it was done this would be the perfect message to advance a frame and go again ... (how to stop on the last frame though ?)
I'm not getting my head around jit.qt.movie basically - metro, stop start and rate are confusing the heck outta me, I get random results that I cant reverse engineer so far to figure out what is going on - is there just a 'play at the .mov files frame rate' option ? or 'step 1 frame' option ?
here is my mess of a patch:
here is one way of many to print out successive frames of a quicktime movie.
each frame's data is stored on a single line in the text object.
basically, a successful read notification triggers the qt.movie to output frame 0, which starts the process. the "done" message from the jit.iter triggers the next frame. notice the "deferlow" object which ensures that the next frame won't be output until the previous frame has finished writing to the text object.
you should study the relevant tutorials if the quicktime object is not making sense to you.
ok,
hi - if you dont mind check out this mess of a patch:
I've had to resort to using a metro and a trigger at the top to sort out the ordering of the function - attempts at other ways around it ended up with the initial frames RGB values being written to the text file 5 times ...
Things I know can be improved = my understanding of how jit.qt.movie and the metros work - I get odd things happening which I'm finding hard to reverse engineer, why does jit.qt.movie need a metro if I just want to jump through frames ?? etc...
Things I'd like control over and to learn how to do:
- - Stop the dicking about when I load the movie (hitting stop, then reseting the frame #)
- - learn how to make the UI easier - I know how to hide all the gumph but not how to set the initial values for jit.qt.movie and jit.matrix (5 and 5 in this case) without going into the thingies thmeselves - I did however manage to make the frame numbers an inputtable field (go me!)
- - Find out how to add line breaks per pixel if need be
- - Find out about what the metro going into jiy.qt.movie is actually doing and why changing the number going into its right inout from 0.5 to 1 made my little patch work better with *much* smaller periods on the metro going to the trigger
- - Find out how to make this work 'offline' so to speak - so it runs in order as fast as it can without clashing timewise - no more metros maybe, and instead 'just go as fast as you can without stuffing up' (possible?)
- - Find out how to remove the Alpha values if need be
-- understand what I've done here !
I am yet to try it with larger files - but in the meantime have been using a little 5x5res x 5frame file - each frame has a white number on it for ID and the black is actually dark grey with its RGB values set to the frame number (easy to see in checking the .txt output)
did you look at the patch i provided? you should not need to use a metro at all.
bangs simply tell a jitter object to output it's current matrix. this information is all in the documentation and tutorials. in the patch i've provided, it first tells the qt.movie which frame to go to, then it bangs that frame out.
check out @autostart attribute to qt.movie.
the rest of what you ask can be achieved with simple modifications to either of the patches posted.