the_man361

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 :)

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. 

Does anybody have any suggestions on how to get the data into max in this way / process it? All suggestions are useful :)


max-patch-to-destroy-jpeg-data

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.

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.

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.

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 :-)

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 :-)
hth
hans


Heh, yeh i figured i probably didnt want to scamble the header or the palette, im just interested in doing the image itself.

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.

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.

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 ?

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.

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.


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)

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. 

(Funny sidenote, i actually wrote the object partly because of this post)


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);
  data[loc]=(byte)random(255);
}
saveBytes("1-mod.jpg",data);
println("ok");
exit();


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.

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.

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. 

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...

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...

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-

https://cycling74.com/forums/sharing-mxj-fileout

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-
https://cycling74.com/forums/sharing-mxj-fileout

MatLab ( www.mathworks.com ) 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

MatLab ( www.mathworks.com ) 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


I used to deal with compression work with the help of some fine 3rd party 

. Choosing a fine tool whose way of processing is simple and fast can make the work much more convenient. Isn't it?

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?


Max patch to destroy JPEG data