Max patch to destroy JPEG data

    May 04 2010 | 7:42 pm
    Hi all
    After a bit of a mistake ive just spent a bit of time playing around opening jpg files in text edit and deleting / replacing random parts of the data with random characters.
    I'd quite like to create a max patch with which i can read the raw jpg data (as ascii characters, say, as a text editor does) and that will automatically mash the data in some way (i.e. step through the data and remove / replace / rearrange sections at random) and either save or (preferably) display the results.
    Does anybody have any suggestions on how to get the data into max in this way / process it? All suggestions are useful :)

    • May 04 2010 | 9:57 pm
      for a bit of fun with computerviruses i once used the filein object.
      you can read in a file, then scramble/do whatever, then you would have to write it out again and then read back as jpg.
    • May 04 2010 | 10:38 pm
      Hi Hans
      filein looks fairly promising, for some reason it didn't autocomplete when I created the new object, so i must have missed it! There doesn't seem to be a complimentary fileout object though, i'm stuck as to the best way to use this. Looks like I could fairly easily write a scrambling type of patch if i could replace data immediately after in the file after reading that part.
    • May 05 2010 | 5:42 am
      collect your scrambling in a text object and write it out, specifying a path and a filename ending with .jpg.
      then you can read back in from there as an image in e.g. jitter.
      just make sure, you don´t scramble the files header, else it won´t be possible to pass as a .jpg anymore.
      and don´t forget to post your patch, when you are finished :-)
    • May 05 2010 | 7:12 pm
      Heh, yeh i figured i probably didnt want to scamble the header or the palette, im just interested in doing the image itself.
    • Mar 16 2011 | 3:02 pm
      Hi there, I have been trying to figure a way to automate this process of destroying the jpeg data. the_man, how far did you get with this patch? I'm struggling with the filein object, specifically with Max crashing as I write as a text object and also with specifying the path and filename. I did find a fileout object that somebody had written though.
    • Mar 16 2011 | 6:23 pm
      In case you have Jitter, it is far more straightforward than with max objects alone to import (importmovie) process and export (exportimage) various image formats including jpeg with jit.matrix.
    • Mar 17 2011 | 11:27 am
      I'm also trying to achieve this effect in an 'analog' way (get the bytes in using filein, modify the bytes randomly then export). I have managed to import the image using the filein + text object but when I try to dump the whole thing in the fileout (no bytes were harmed at this point), I only get a 4KB image instead of 34KB... Does anyone have a theory on this ?
    • Mar 17 2011 | 10:11 pm
      i checked your approach. same problem. maybe max can't pass such a big message at once or fileout can't take it.
      i must say i was expecting that fileout can handle single bytes and write them. it's not really the complement of filein.
    • Mar 18 2011 | 8:00 am
      Hello folks,
      Cool to see people using the fileout, uncool to see it doesn't work as expected. I checked and indeed, when exporting you're left with a 4096 bytes file. I must admit i actually have no idea why or how this is possible. My guess is this limit is imposed at either the list message (a limit of no more than 4096 ints/bytes?) or some issue within Java.
      I'll check if i can rewrite the fileout so it won't require a list for input but instead have int's stored in an internal array. Maybe that will help? Any help/suggestions are welcome...
      (Funny sidenote, i actually wrote the object partly because of this post)
    • Mar 18 2011 | 10:36 am
      Hi FRid,
      Thanks very much for looking into it !
    • Mar 18 2011 | 12:00 pm
      If you can't wait and want to go ahead anyway i've had succes with this processing-code (not mine, found it on the processing-forum).
      byte[] data=loadBytes("1.jpg");
      for (int i=0;i int loc=(int)random(128,data.length);
    • Mar 21 2011 | 2:01 pm
      Hi FRid
      Really grateful for both your Fileout and the helpful processing code. I just executed the code for the first time and am managing to get some satisfying results. I'd love to get it working in Max as I am more literate here and think I'd find the process easier to automate and control. I've set up the same filein/text object dump as nnimar so I wont bother posting the patch. look forward to hearing your thoughts on a possible solution to the 4KB file limitation. Thanks so much again for the tool and reference.
    • Mar 23 2011 | 4:15 pm
      Hello people,
      Found the problem, although the fileout is working correctly (so far). It seems the problem lies within max, i've made a patch that shows what goes wrong. Now i've tested this with a 7069 byte (jpg)file and it stuck at 1216 bytes and also used a 86521 byte file which stuck at 1619 bytes.
      Can anyone reproduce this? I'm a bit puzzled to why and what is really going on. If anyone knows what's up please do enlighten me. Funny to see it still does what the title says but i guess it's destroying the jpg's a little too much now.
    • Mar 30 2011 | 6:02 am
      Scrambling a jpeg image in text format seems like trying to walk from Berlin to Tokyo instead of flying, a ship would be the minimum possible...
      If I understand you correctly, you want artefacts of errors in the jpeg compression, I would do this directly in mxj, I bet there are libraries which can decompress jpeg, just feed them from filein and scramble some values before you decompress the image. Then send it to jitter for display...
      But maybe this has been done already, ask for it on the jitter forum, there are the experts for images and their formats, they also know how to degrade images...
    • Mar 31 2011 | 12:13 pm
      We don't walk, we cycle :) and although i'm cycling i'm still taking small steps one at a time.
      Java/Mxj isn't nice to me most of the time, i do have the vocabulary but the grammar remains obscure to me most of the time. I agree it can be done faster but the limit is imposed by filein and the way you have to get the bytes out. A message to dump all the bytes at once would surely help improve speed. Plus this way it's not only limited to images, any filetype can be used. I've tested an -aiff and this gets scrambled nicely as well.
      Anyway the new fileout is available here-
      [attachment=158179,1998] [attachment=158179,1999]
    • Apr 26 2012 | 9:18 pm
      MatLab ( ) has some image processing functions you might wish to emulate..
      i wonder if anyone has tried to integrate the two:
      in a DSP class i took we used MatLab to load the (compiled) object code to design a GUI for real-time audio processing, so it is highly probable MAX can call MatLab functions, and return data
    • Oct 21 2013 | 4:10 am
      I used to deal with compression work with the help of some fine 3rd party image compressors. Choosing a fine tool whose way of processing is simple and fast can make the work much more convenient. Isn't it?