Hello Sup Forums
As you might know, Google Photos allows infinite storage of photos and videos (although they get compressed first). I was thinking about creating an infinite storage mechanism that encodes data into pictures. Would this work? What's the most efficient way to store data into a picture that so that you can retrieve it later after it has been compressed? QR-codes should work, but it's not very efficient in both computation power on the client side and file size.
yeah its infinite until google realises dogfucker.03 is using 90TB of disk
This would be only worthwhile if your time is worth nothing.
It would be incredibly inefficient and slow.
Run dd if=/dev/null of= instead and you will overwrite all data on Google's servers.
Is it hard to automatically generate Google accounts? Will Nocaptcha Recaptcha fuck me over?
Seems like a fun project to me
It does work. People used to share images with hidden files inside all the time on Sup Forums. Never download an image of a sink.
Sup Forums doesn't compress images, that does make it a lot easier (4 bytes per pixel in the r, g, b and a channel)
How much space do you need that you came to think about this?
this
exactly this
Isn't it the other way around?
Ok, so you fly under the radar a bit longer. Then Google finds the metadata and blocks it. Beyond that, this can't be that much data.
Or a person can buy a 1TB hard drive and store their private data locally, without having to constantly waste bandwidth on download and uploading private data to someone else (Google in this case).
Not a whole lot. I was just thinking about this. It would be really cool to have a seamless FUSE filesystem of infinite size that seamlessy creates new google accounts and saves data in pictures
They already did this but for YouTube uploads and encoded files in the same way.
And it was a fucking disaster
Link?
The project is out there and there were threads months back about it. I don't remember its name. I tried jewgleing some keywords but I am coming up empty. Good lack.
It won't work on google pics, might work on flikr since they don't convert the data.
There's still data in the processed pictures, just a little bit less of it. It's just a matter of finding the most efficient way without chance of data corruption.
How are you going to take a big file an run it through the google compressing scripts and after get a file that can be uncompressed in order to get yo shit?
Take a fully black or fully white image for example. I'm able to store 1 bit of data that way. Now split up the image in 4 different squares, and make each of them either black or white. Google wouldn't fully throw away all data, and you would still be able to retrieve the 4 bits of data you put into there. It's just a matter of looking how far you can go. You can probably throw some colors in there too for an even higher data density.
I remember a guy that combined a picture with a big archive and used the picture extension, uploaded all that to flikr(1TB storage) and it worked.
Can't remember how he did it.
Can anyone tell?
>Would this work?
Yes, I already do this.
>What's the most efficient way to store data into a picture
Use GdipCreateBitmapFromScan0 with PixelFormat32bppPARGB to create a blank image
Use GdipBitmapLockBits to get the the pixel data buffer from the blank image
Write the data you want to store into the buffer
Call GdipBitmapUnlockBits
Save image as PNG with GdipSaveImageToFile
You can store 4 bytes of data per pixel. The resulting image will generally look like a bunch of randomly colored pixels. The data can be retrieved by reading the pixel data buffer and writing it to a file.
People still share these images btw.