Texture UUIDs, Pattern recognition, and *shudder* copybot

It seems to me that a decent way investigate both texture theft and copybot issues would be through a database query system.

For texture theft via GLintercept or the like: pattern recognition software is very common - law enforement uses it commonly for fingerprint matching, and anyone who has used OCR software, has used pattern recognition. Now I know it's a monsterous task, but seems to me that LL could set up up some sort of database query system for just such a purpose (only because they control the database). You could do a query based on the uuid of a texture you own, and see if pattern recognition could flip through the thousands of images in the database for a match. Not saying it would be quick or easy, but then you could limit the number of searches by a week limit or the like. A search like this would settle issues fairly well - because unless the database is ridiculously simplistic, it should list date of creation (upload) and the creator of the textures in question.

This also got me thinking about copybot (just recently got threatened and put on someone's "list" of suspected copybot terrorists because I did the responsible thing and actually tested [before the TOS violation announcement] it rather than give in to the hysteria that breeds panics like the viruses that supposedly erase your harddrive). From what I could see, it created all new prims using the specs of the originals, but applied the same texture that the original had - therefore, it should have the same texture uuid as the original. Hence: a uuid search listing all objects using that texture, and who the creator is. You could easily filter out your own objects, and that would leave you with only entries for objects created by others using your texture.

Just my two beans....
Cheers!
Solivar

Hi Solivar

One scenario could see two people at different times uploading a texture they "borrowed" from some web site and which each claimed as their own. Would it be your intention that the data base query would match the textures themselves and highlight these two uploads?

That would be a pretty gigantic task. Watermarks such as used by ebay might be simpler.

Ed

In that particular case, niether party can validly claim ownership.

Exactly - or possibly using a difference algorythm <sp?> - I use image differencing a lot in my line of work as a way for creating fast and dirty masks for things not shot on greenscreen. Of course, it would have to be a pretty narrow differencing as, for instance, a lot of the clothes I make use the Robin Wood template, and I sometimes leave a portion of her copyright message or the grid visible, so that would be something that would match up clearly, but in fact be far off the mark for the actual texture in question. It would, by this narrowness, skip a lot of cases of theft where only a portion of a given texture has been lifted - say, just the face out of a whole head, or a logo off of a an entire shirt.

Watermarks would be simpler, however that would only help from the time of implementation onward. Most folks don't watermark. And yes, it would be a mighty mighty undertaking in processing time and power - hence Linden Labs could even charge for it, like most places do for database searches.

You're all forgetting that textures are almost never used raw.

In the case of avatars, they can only actually carry a single image map per geometry group at a time. When displayed, the layers of clothes, plus the skin tattoos, plus the original default skin are all baked together into a composite before being rendered. If somebody's going to rip your textures, what they're ripping is the baked composite, not the individual textures that make up the clothing layers.

The compositing process trashes any watermark you might try to put in the image, with no way of recovering that watermark. It may even change the color space of the images you uploaded to facilitate this compositing process.

Further, you only get full texture resolution when you're a couple of meters away from the avatar or object upon which the texture appears. Beyond that, the texture is reconstituted to a lower resolution for display in a process called mip-mapping. (This comes from the Latin phrase, multim in parvo, which means "many in a small place".) Again, when this happens, your watermark is destroyed. The further away the object is from the camera, the more your original images have been scaled and subdivided for display - it's a speed optimization, common to all modern computer games and 3D display software.

"But what about signing it in the corner where it's not normally displayed?" you might ask. This may work, but it may not, depending on what other images have been composited with it. I'd guess probably not - unless you go out of your way to make your signature against an alpha transparent part of your image, and every single image you make has that signature in a different place so that if they do get composited together, you won't get an overlap that destroys both signatures.

Assuming, then, that your texture has been stolen, how would you determine this? The only way is to use the same tool the thieves used to steal your texture in the first place. This puts you on the same moral level as the thieves, because now you're stealing copies of their textures. And when you look on your hard disk for the images, you'll find that the tool you used to capture the images has not saved the original format of file you may have uploaded to SL - it's dug them out of the OpenGL card and written them to the disk in a new file, using a format you probably didn't use to upload it with. The color space will have changed, the file format is changed, and the gamma may even have been compressed to make it more compatible with the OpenGL display you're using. In essence, your chances of having a usable watermark are zero.


Beyond this, SL automatically converts your uploaded images to another format, probably destroying any embedded watermarks in the process. This is a technical requirement - it has to have a unified image storage format in order to use images on the massive scales required.

I've seen all kinds of discussions of DRM for images, and so far none is workable given the basic technical requirement that they be reprocessed, transmitted, and coverted at least three times before you even get to see the results. The bottom line is that you're never ever going to see watermarks in SL.

Ever.

1. Fingerprints are predictable enough for pattern recognition to work.
   
2. Characters are predictable enough for OCR software to detect.
   
3. Textures on the other hand are a whole different ball game.
   

I doubt the technology even exists that would allows us to analyse textures and compare their visual similarities to hundreds of thousands if not millions (surely?) on a database, and I doubt Linden Lab has the budget to finance such a project. And lets not forget that the database in question is already over-burdened and constantly falling over due to astonishing increases in demand.

At the binary level, it's not going to work either. Why? Because the program you mention (and please try to avoid mentioning it here ) doesn't give you the original TGA file that was uploaded, and the binary data inside the file you get is completely different from the original - even though the image looks identical to the human eye.

Took a brief look at the cerious page but couldn't figure out which product I'm supposed to be looking at. But bearing in mind my exact quote:


So software exists which can compare two images which look the same (or very similar) to the human eye, but differ in binary code and at pixel level? And it can do this with tens of thousands of images a day in the space of a few seconds?

If it can do what's stated in the first sentence alone I'm impressed. If it can also do what's stated in the second sentence, I'm flabbergasted. Wowz.

Actually, using differencing technology would work quite well - it overlays two images and looks for areas of difference - down to the pixel - so for instance, if 20% of an image matched, even with the flattening the something like GLintercept would introduce, it would still pick out the areas where they match. it's doesn't have to recognize the exact image, just catalogue the pixels that show up in the same place from image to image - to make it easier, it could just use search regions. I used to be able to run a small line command app on the sgi that would difference a whole sequence of images against a single "clean" 2k plate and spit out a differenced image based on that in nothing flat - and that was 10 years ago - now it's a basic mode for photsoshop.

All of this completely ignores the hoops each image has to jump through to become rendered on your client screen. Your images are so heavily reprocessed that there is zero change of a watermark surviving in recoverable form. I know from where I speak - if you watermark your original, you can test that original against the watermark.

But we're not talking about your original artwork here. We're talking about your artwork after at least four generations of reconstitution, each generation of which is to satisfy the technical requirements of the next phase in its eventual delivery to the client.

When the image has been recompressed, translated four times into different storage modes and color spaces and pulled out of the graphics memory of your video card as a buffer of raw bytes that have been compressed into the color space your video card is capable of handling, there is zero chance of survival for any sort of watermark scheme.

It just isn't ever going to happen, and there's no way to make it happen. Additionally, even if a watermark comparison process could be automated (which isn't possible due to the tremendous computing resources that would require - remember that for Photoshop to do it requires the entire resources of your computer to process but a single such comparison for the time it takes to do that) it would be unable to compensate for something simple like the addition of a second watermark. It only works if the plates involved are unmodified, which in the SL environment, is never the case.

Please reread my post if you're still confused.

Okay, so baking and so forth may potentially destroy image watermarking. (Has this been tested for certain?)

What this seems to indicate, is that it is LL itself that should implement a watermarking feature server-side. For the last step after baking, all textures receive LL's own watermarking, with data such as the owner's GUID and the date.

Still, how would this prevent texture theft? Someone could still upload a stolen texture and have his watermark stamped on it.

Scanning every texture ever uploaded for matchup when trying to upload something is just absurd.

I did read your bit about image degredation vs watermarking, and it's likely so; it does not however negate the possibility of image recognition differencing. Yes, it seems unlikely, but as a concept it's moderately sound - sound enough for someone to possibly test at least. Yes, I'm aware that there are hundreds of thousands of images to search and apply the process to, but while unwieldly and unlikely as it is, it's not impossible. New ways of doing things happen every day, and often spurred by an "impossibility". I'm not one who sits well with the attitude of "it's never been done therefore it can't be done."

Just suggesting a possibility, not challenging anyone's worldview after all.

PS: I didn't suggest it as an upload scheme - my idea was for a formal request system - possibly for charge - probably on the website, and with no expectation of immediate feedback - hence the week wait between requests. This way, if you suspect a texture of having been stolen or used elsewise, you can have a formal trail to submit for adjudication.

Do you even know how a watermark works?

Watermarks work by adding data to the pixels in the green values for the pixels in the image. It takes a lot more change in the color green to be perceived by the human eye than the same change in the red or blue channels, so they use green. They bump the pixel values using a two color watermark image, pixel by pixel. When you use this same watermark image and unpremultiply the pixels, the watermark image reemerges.

Watermarks are destroyed by compression schemes - they have to be numerically accurate to work at all. Likewise, baking is a process of numerical multiplication, and then renormalizing the resulting color values back into the colorspace of the original image. This rescales each pixel value for R, G and B back into the numerical range the image format is capable of supporting. It's not like a watermark on a piece of stationary. This isn't something you have to test. You can work it out with pencil and paper and prove it mathematically.

You're missing the point anyway, here, Scalar - even if they did that, a baked texture is one that's been processed and probably combined with one or more other textures. Each time that's done, a new unique texture is created for the purposes of displaying it.

There's a nearly complete disconnect there. It's not transmitting your texture to the client for rendering. It's been repeatedly mauled and reprocessed, recompressed and combined with other textures, information unnecessary to the (reasonably) accurate rendition of the original texture has been stripped out, and you're viewing a reasonable facsimile of the original, not the original. The original version in its original form is lost the second you upload it. SL never even sees it. The only one with a working watermark on it is on your hard drive on your personal computer.

For example, your image has to be scaled either up or down to the nearest power of two before it can be displayed on an OpenGL card, so SL does this as a first step on upload, then recompresses the resulting image in the SL standardized format, whatever that is. IMMEDIATELY, the image is no longer in its original format, and any watermark you put on the image is instantly lost. There are watermark-damaging processes at work at every stage of the process, and there are more than a few of these steps. I mentioned at least four earlier - there may be more than that.

Some of these steps cannot be rewritten or circumvented, because they are dictated by the demands of your OpenGL graphics card. Other steps are required to standardize the graphics images for the purposes of storage on the asset servers.

It's just not gonna happen, people.