Chris Millar Posted March 29, 2010 Share Posted March 29, 2010 Hello, I'd like to learn how to read a video file 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. Where to start ? Oooooor - perhaps this backasswards approach is silly as there is some file format I can easily transcode any given footage to that is in essence what I want anyway ? Any help appreciated Link to comment Share on other sites More sharing options...
Premium Member John Sprung Posted March 29, 2010 Premium Member Share Posted March 29, 2010 Way back in the DOS days, one thing we could do was take a freeze frame into PhotoShop, and save it as a .BMP file. Look at the .BMP in DEBUG, and in the dump you see the RGB triples in hexadecimal. Dump to a file, and you have it in ASCII Hex. Had I wanted it in base ten, I could have written an assembly program to do that. What I did with that was to write a program that simulated the problem of encoding something as 601, and decoding it as 709, and vice versa. That was one of the things we worried about back in the formative years of HD. -- J.S. Link to comment Share on other sites More sharing options...
Chris Millar Posted March 31, 2010 Author Share Posted March 31, 2010 Gidday John, I ended up writing a patch in Jitter (cyling74.com) to do it for me ... OUCH amounts of data (should have thought of that) - I've rethought the way I'll go about it which means I need to understand .tiff files - I'm reading through the spec at the moment (http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf) and downloading resorcerer for OS X - I think I should be able to search and see hex values directly instead of using a text editor like I am at the mo' ... Speaking of which, I made two uncompressed 1x1 pixel greyscale .tiffs in photoshop - one full white pixel the other full black - everything else completely the same then compared the two files in a text editor White: <tiff:NativeDigest>256,257,258,259,262,274,277,284,530,531,282,283,296,301,318,319,529,532,306,2 70,271,272,305,315,33432;DCD6C0D6F317D2C4B5156D7FC7F68A56</tiff:NativeDigest> Black: <tiff:NativeDigest>256,257,258,259,262,274,277,284,530,531,282,283,296,301,318,319,529,532,306,2 70,271,272,305,315,33432;D895E4270CDCEAABC5E197F53297EBF8</tiff:NativeDigest> Out of all the lines only these two were different - why so much data ? I was hoping to see maybe 00 and FF or similar Back to the books ;) Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now