Writing random bytes into any complex file type is just going to give you a corrupted file. JPEG in particular does compression, so even just writing to the compressed pixel data sections could corrupt it. According to the links, the compressed image data is between the "Start of scan" and "end of image" markers, so I would first try to locate those by parsing the file. Here's some tips from an SO post: https://stackoverflow.com/a/1602428
What exactly is your goal? To overwrite actual pixel values? Or to modify the compressed data?
Why not use a library to load the image as an array of pixel data, then modify that pixel data and write it back?
Of course, even if you did it the latter method, JPEG is still tricky since it is lossy, so whatever data you're trying to weave in there will also be subject to loss; my first idea would be to apply some error-correcting codes (coding theory). PNG, on the other hand, would not be lossy.
Depends on what you mean by 'manually'? Again, if you are writing to the compressed image data directly, you'll probably just corrupt the compressed data, or you'll modify multiple pixels at once in non-obvious ways, not every 50th.
If you mean 'manually parse and decompress/recompress the JPEG data': It might be fun to write your own JPEG decoder/encoder, but it sounds like a massive time sink if you're just looking for a practical solution.
I thought the file format of jpeg would be a lot simpler than it is, I thought it would just have a header with all of it's various metadata then I assumed that after the header it would just contain the rgb values of each pixel, couldn't have been more wrong,
is that any image file format close to what I described above, BMP even looks complicated from what I can tell and that is supposed to be one of the easier ones.
to stress the above: jpeg does NOT store images as raw pixel values, and trying to hide a message in one is going to cause trouble. Likewise, hiding a message in a raw RGB array and then converting that to jpg will LOSE most of the hidden message unless you use lossless jpg encoding.
that is the ONLY way to do this with jpg, really... is to convert the jpg to RGB, put your message into it, save it now in lossless format. Opening this lossless and converting it to RGB will now have the message in it. The size will increase slightly to save as lossless if the image was jpeg to begin with. It will be larger than usual if you started with an uncompressed format to begin with, like png, as a jpeg.
honestly it may be best to do it from the inside out.
make a RAW image format tool to do what you want to do, and you can apply the jpeg front and back ends later. RAW format is simply a binary file of RGB bytes (optionally store the dimensions in the first N locations, eg 2 16 bit ints). Several free image programs can store and load images in this format. Get that working, and worry about the format later.
BMP is one of the easier ones. It has uncompressed byte data in BGR order. One of the first C++ programming books I read actually had an example of loading a BMP image and modify, although I don't have it now. If you want a challenge that isn't too difficult, writing/reading a BMP image yourself would be reasonable.
I always used uncompressed tga, which is similar to above but in standard RGB order. Order doesn't matter, though, if you are doing every Nth byte. Trying to remember.. humans see fewer shades of green than R/B so tampering with the low order nibble of greens on every 10th pixel or so barely touches the image?
Thanks Jonnin, that also sounds like a pretty fun yet complicated project but I'll give that a shot after I try to modify the easier BMP file
there isnt any point; the raw idea is similar to the bmp idea, exact same thing except bmp has more fluff in its header before the data starts.