where there’s smoke there’s forum fire
It's still a very grey area and it would be up to the courts. Just look at Shepard Fairey "Hope" poster.
http://en.wikipedia.org/wiki/Barack_Obama_%22HOPE%22_poster
That was taken from a photo too and that's not a cut and dry case either.
But regardless of the legal angle, the point is that this software makes it so easy to "steal" photos in a way that lets anyone, regardless of skill, take your pictures and create new work.
If it helps you sleep any easier, NikoDoby, software such as this will rely on a back-end database. Even if treed hashes were the only thing stored about each photo (I doubt it as there would be an easy way to block usefulness of said hash-only solution (more on that later)) it would be a massive database and assuredly be on a centralized server with the client software searching said database.
Being that it would be reliant on a back-end database - that means there is one point of legal attack. The alternative is to ship a (still huge) hash-only database which would /link/ to the original photos. Overnight you could simply patch most gallery software to randomize image filenames and correct links to said photos on a nightly basis. This would kill the usefulness of any hash-only database and would mean that for the software to work without a central server every single end user would need to be given the photos themselves - which would be a black-and-white copyright violation.
So you know how this software works now?
We can postulate quite a bit from current tech which does many of the same things - regardless of "how it works" the limits on data storage at the end-user level will be common.
Tineye is a identification based photo search engine, and craws the web and downloads images. It currently has 1.12 billion images in its database. If only a 8KB hash was delivered to every end user about each of those images we are talking 8.5 Terrabytes of data. This MUST be on a central database. (PS - tineye's 1.12 billiion images are nowhere near enough to find sources for any but the most popular of images)
Piximiliar is considered state-of-the-art when it comes to searching for similar images. They flat-out say the service is not metadata or keyword dependent. This means image parsing, but not necessarily image storage. Already I have shown how a small database of just parsed hashes takes more storage space than can be delivered reasonably to an end-user.
So let's say we can be confident this is a server-client solution. (I think the storage numbers involved speak for themselves). That means only one of two things - the server either stores the original images itself OR the server stores LINKS to said images. If it stores images it is subject to copyright law in and of itself. If it stores links a randomization scheme such as I briefly outlined above will kill it.
See? Logic can answer questions even when we don't know details.
EDIT:
Keyword or metadata based options are POSSIBLE, but improbable. The advantage is they would could cut the size of the database down by an order of magnitude or two (85 GB is still too much to give to an end user) but they would require sophisticated tagging of hundreds of million of images, and not be as successful at matches as the recognition-based systems currently deployed - they have been tried and have failed so far. If you have the recognition engine to parse a drawing and know what to look for going from fingerprint -> keyword -> fingerprint is a needless and error-prone step as well. Better to just do a fuzzy search on fingerprint->fingerprint.
EDIT2:
But let us run with the idea that this is keyword / metadata and not recognition. As I started to say earlier recognition has worked better so far because you don't need to know X=Apple and Y=Apple, therefore X might look like Y, you know the X and Y share enough similar traits that they are likely the same (or more importantly, same enough without building the huge database of Apples, pears, oranges, etc etc).
Metadata is an unlikely one in this case because it works off a sketch. It would be much easier math to parse a sketch similar to the way you parse an image and look for those fingerprints than it would be to _unaided_ assign relevant keywords to a sketch, then look for those keywords - not to mention the already discussed monumental task of keywording millions and millions of images.
Then we get to the other flaw of metadata: Pose.
It is not enough to know, when attempting to duplicate a sketch, that it IS a girl, you need to know how the girl is posing. Using already available metadata (if you wanted to pick-and-choose your source material from well-tagged sources such as flickr) to answer the problem of how to tag so many won't give you pose information.
If we assume an incredible 20 bits of information is all it would take for a metadata solution (that's ~1 million unique values only) that's about a DVDs worth of database to end-user. Doable - but only 1 million unique keys to describe 1 billion unique images.
Of course the software is useless to me because I can't draw :)
Not even stick figures? As the demo shows that's all you need to draw! lol
I drink a lot of coffee Niko... It's not as easy as you think LOL
Well I just drink a lot and my stick figure drawings are now in the MoMA permanent collection. :^)
There is no storage issues that I can see with the system. All they need is a shortlist of images returned from google and they can then start with their "clever bits" the result is several images and the user chooses the one they like best. Could be fun at first.. but would get old soon .. I think.
That system is admittedly possible, heartyfisher, but is vulnerable to the randomization of filenames patch as I addressed. The whole talk about a central server was the one way _I_ saw to get around such a image protection scheme.
Google would need to index you page AT LEAST as often as your link scrambling perl script ran to be able to successfully lead people to your images. As the resources needed to run such a script are smaller than the resources needed to spider a web page the battle could easily be won by the photo hosts.
ANY method which caches the images could defeat the randomization trick, but I was pointing out that storage was a serious concern if you DIDN'T want to use a central server, because of the legal vulnerabilities centralization entailed.
Dont think it needs consistent sets of images .. as long as the "tags" bring back a couple of hundred images that fit the criteria say "dog" or "lake", it can do its "magic". So caches are not needed (moot). each time you run it it should create different sets of images for you. It looks like a way of creating random images based on your criteria of tags and shapes. I dont think scrambling will effect it as long as there are tags which the image provider will want to be accurate anyway.
If path to the photo gets scrambled the app would have to rescrape the web to reassociate tags with photos, and in that arms race the amount of effort favors the scramblers over the scrapers.
It seems to me that the images used for the montage would have to be fairly high in resolution before you could ust it for much more than just a time killing toy.
You must log in to post.
