FA+
Shop
1608
Views
Views
14
Favorites
Favorites
Category
Resources / Tutorials
Species Unspecified / Any
Size 1030 x 508
File Size 360.5 kB
Report this content
More from nobuyuki
Hello,
this is a method I decided to test today after some consideration with regards to the rather draconian measures employed by certain online content providers which require artists to destructively censor their work (known as adding a mosaic, "pixelating", or "masking"). The method is most useful for western artists under no such restrictions who utilize these sites, specifically western artists who sell their work on Japanese sites such as DLSite, etc.
The method can be employed into an automated process which serves as a secondary distribution channel for content needed to "uncensor" or essentially recreate the original, uncensored images, by applying a specific filter to the image. Neither the original data nor any method to "uncensor" the data need be hosted on the primary distribution channel, completely avoiding issues related to legality in the host country and the primary distributor's Terms of Service / Acceptable Use Policy.
I call the methods used for this process the "D" (De-mosaic) and "R" (Re-mosaic) filters. Together, they make the "DrMosaic" application. How it works is described in the image. The following is a reference implementation for the technique, in HLSL:
sampler2D img;
sampler2D bkd : register(s1);
int dm = 0;
float4 ps_main(in float2 In : TEXCOORD0) : COLOR0 {
float4 O = 1.0;
float4 orig = tex2D(img,In);
float4 mask = tex2D(bkd,In);
if (dm==0) {
O.rgb = 0.5 + (orig.rgb-mask.rgb);
} else {
float temp = 0.5;
O.rgb = (orig.rgb+mask.rgb) - 0.5;
}
return O;
}
technique tech_main { pass P0 { PixelShader = compile ps_2_0 ps_main(); } }
Some advantages to the method: 1. It's not necessary for the final, masked image for the end-user to be compressed losslessly, therefore any sort of distribution on a variety of paid content hosting sites will suffice, as will a variety of censorship techniques. 2. A secondary channel need not be specifically secured to host the diff images. This provides an advantage over requiring a secure secondary channel for an entire uncensored image set. 3. The method avoids any potential legal issues in the host country, as no diff files need be distributed on the primary channel, and in fact the uncensored image cannot be recovered from destructive masking.
I hope you will find this technique useful; in the future, I may sell (or give away) a tool which can be used to create separate "destructively-masked" images and their diff files, and a separate, free tool or script for the end-user to piece them back together.
(The source image I used belongs to BONZU / 少林ボンズ. Thank you.)
this is a method I decided to test today after some consideration with regards to the rather draconian measures employed by certain online content providers which require artists to destructively censor their work (known as adding a mosaic, "pixelating", or "masking"). The method is most useful for western artists under no such restrictions who utilize these sites, specifically western artists who sell their work on Japanese sites such as DLSite, etc.
The method can be employed into an automated process which serves as a secondary distribution channel for content needed to "uncensor" or essentially recreate the original, uncensored images, by applying a specific filter to the image. Neither the original data nor any method to "uncensor" the data need be hosted on the primary distribution channel, completely avoiding issues related to legality in the host country and the primary distributor's Terms of Service / Acceptable Use Policy.
I call the methods used for this process the "D" (De-mosaic) and "R" (Re-mosaic) filters. Together, they make the "DrMosaic" application. How it works is described in the image. The following is a reference implementation for the technique, in HLSL:
sampler2D img;
sampler2D bkd : register(s1);
int dm = 0;
float4 ps_main(in float2 In : TEXCOORD0) : COLOR0 {
float4 O = 1.0;
float4 orig = tex2D(img,In);
float4 mask = tex2D(bkd,In);
if (dm==0) {
O.rgb = 0.5 + (orig.rgb-mask.rgb);
} else {
float temp = 0.5;
O.rgb = (orig.rgb+mask.rgb) - 0.5;
}
return O;
}
technique tech_main { pass P0 { PixelShader = compile ps_2_0 ps_main(); } }
Some advantages to the method: 1. It's not necessary for the final, masked image for the end-user to be compressed losslessly, therefore any sort of distribution on a variety of paid content hosting sites will suffice, as will a variety of censorship techniques. 2. A secondary channel need not be specifically secured to host the diff images. This provides an advantage over requiring a secure secondary channel for an entire uncensored image set. 3. The method avoids any potential legal issues in the host country, as no diff files need be distributed on the primary channel, and in fact the uncensored image cannot be recovered from destructive masking.
I hope you will find this technique useful; in the future, I may sell (or give away) a tool which can be used to create separate "destructively-masked" images and their diff files, and a separate, free tool or script for the end-user to piece them back together.
(The source image I used belongs to BONZU / 少林ボンズ. Thank you.)
Category Resources / Tutorials
Species Unspecified / Any
Size 1030 x 508px
File Size 360.5 kB
I have seen (and used) an application like this. Found in the lowest and darkest places of the japanese forums.
I should still have this software saved somewhere in my oooold backups... when I used to visit said forums...
I downloaded a censored picture from the forum and used the tool to uncensor the pics (in mosaic just like you mention here)
I should still have this software saved somewhere in my oooold backups... when I used to visit said forums...
I downloaded a censored picture from the forum and used the tool to uncensor the pics (in mosaic just like you mention here)
The biggest difference between the technique I described and tools like GMASK is that without the diff file created by my technique, any kind of destructive mask can be applied to the image, which makes it less likely to be illegal in the host country. By distributing the destructively-masked image and a diff file separately, or by not distributing the diff file at all, the masked image can be safely distributed, and is technically indistinguishable from an image where no drmosaic diff file exists.
Any chance that the diff image could be covertly embedded into the original image somehow? I know (or at least think) that some image formats support additional channels other than RGBA that simply won't be rendered by typical image viewers but are otherwise still discoverable by programs that support additional channels. E.g., some digital cameras, I think, will capture infrared and store it in a channel in the JPEGs it produces such that it doesn't show up when the image is viewed normally, but the infrared channel can be accessed with other tools such as Photoshop.
One advantage of including the diff image right in the file might be that special viewers (or plug-ins for other viewers) could detect the diff channels in an image and apply them automatically. This way, the image might appear censored in a web browser, but when saved and viewed by a supporting viewer, will appear uncensored, or at least allow the viewer to give the user the option to view it uncensored.
I don't know anything about auxiliary channel support in common image file formats, but it might be something worth looking into for your project.
One advantage of including the diff image right in the file might be that special viewers (or plug-ins for other viewers) could detect the diff channels in an image and apply them automatically. This way, the image might appear censored in a web browser, but when saved and viewed by a supporting viewer, will appear uncensored, or at least allow the viewer to give the user the option to view it uncensored.
I don't know anything about auxiliary channel support in common image file formats, but it might be something worth looking into for your project.
it could be stored in JPEG thumbnail data, but 1. there are already programs which create a non-destructive, reversible mask on an image, and 2. Those methods are not kosher or legal in most of the places where they would be advantageous. The entire purpose of this method's splitting into separate files is to be able to make the primary distribution channel for the masked image clean, whether it be for legal reasons, or simply to abide by the rules of the primary distribution channel.
Is providing a method or data (such as a mask) that can be used to uncensor a particular image in countries/communities that enforce censorship actually illegal/against the rules? I know that's too overbroad a question to answer, but it seems odd to me that even one place would have legislation specifically prohibiting reversible censorship. Then again, I don't know anything about that sort of thing. Either way, if distributing the mask through the same channel as the image itself would be problematic, and thus an alternate distribution channel is necessary, why not just share the uncensored image itself over said alternate distribution channel instead of the uncensoring mask? I could understand that being useful maybe if someone lived in a country where posting uncensored pornography was illegal, and said person wanted to post an image to some site where sharing the mask was prohibited as well, then the person could share the mask through a separate distribution channel and be in the clear, but that seems a bit convoluted. Plus, that doesn't seem very "automated" to me -- having to download and apply a mask manually.
What might be useful then is a sort of dedicated, centralized service that provides such an alternate distribution channel. Perhaps it could match the MD5 hash of a censored image with the uncensoring mask and maybe some additional metadata, and allow clients to ask if an uncensoring mask exists for a given image. The service could then provide the mask if it exists, and the mask could be applied automatically by a client program and then shown to the user. But that just doesn't seem very elegant to implement, nor does it appear the uncensoring mask technique would be more useful than just serving the uncensored image itself. That's really the only way I could see having a separate file be useful as far as having an "automated method" goes. If a user has to manually apply the mask themselves using a third-party program, I don't think it will readily catch on. Part of the reason no one uses Gmask anymore, I think, is that it's a pain to open each file, select the small censor, find the correct filter, and re-save. That quickly becomes annoying, and thus discourages continued use.
I think your algorithm is really cool, because it allows an artist to make any kind of censorship reversible, not just a specific filter ala Gmask. But I don't think a user would willingly go through the trouble of downloading and applying an uncensoring mask for each image he downloads, nor do I think an artist would be willing to go through the trouble of generating them and sharing them. It quickly stops being automated once you require manual intervention like that. It also doesn't make sense to me that an artist would both require that 1) the image and mask be separate files distributed through different channels, and 2) that the uncensored image itself can't just be shared over the second channel and thus bypass the need for additional software. Maybe I need this explained more clearly.
I think what would make your algorithm truly useful is if the mask could somehow be embedded into the image covertly, and in a way that the artist has plausible deniability if it were discovered that he were sharing an uncensored version of his artwork. He wouldn't, technically, be sharing the uncensored images, just two pieces that when put together in the right way reveal the uncensored image. It's then simple to have, for example, a Photoshop plug-in to embed the mask in the file and an xnView plug-in to detect and apply the hidden mask automatically when the image is viewed. Ideally, the image would render properly (censored) in a browser or standard viewer, and would be totally compliant with whatever file format were used to encode the image, but only with a special viewer (or a viewer with a special plug-in) would the hidden mask be detected and applied, thus revealing the uncensored image. The whole time, the artist was technically not sharing the uncensored image, just the parts necessary for a special viewer to reconstruct it. This is possible so long as an image format supports arbitrary-length application-specific metadata. It need not even be auxillary color channels. JPEG supports application-specific header data, I know. I believe PNG does as well, or could perhaps be exploited a bit to do so (e.g., adding image data after the end-of-image marker). One simply need stuff an extra image (the mask) in the metadata, and voila. Now you just need one plug-in to write and one plug-in to detect such images. A plug-in only needs to be installed one time, and could be designed such that the user need make as little a change to their normal behavior as possible. That is certainly much more convenient, and thus much more likely to catch on, than requiring an artist to create a mask for every image, upload it to a secondary image dump site, and somehow tie it to the censored image, or a user to download and apply the mask for every image they want to see uncensored.
Sorry for the wall of text! I'm legitimately interested in the development of a way to circumvent censorship laws legally and easily in places where doing so is difficult, so I somehow felt the need to run my stupid mouth over multiple paragraphs to try to make a point. If you're interested, though, and I didn't sound like a rambling retard just now, I would be interested in developing something like this with you. We could talk about it more, maybe. If you're interested, of course. i am C porgrammer btw lol
What might be useful then is a sort of dedicated, centralized service that provides such an alternate distribution channel. Perhaps it could match the MD5 hash of a censored image with the uncensoring mask and maybe some additional metadata, and allow clients to ask if an uncensoring mask exists for a given image. The service could then provide the mask if it exists, and the mask could be applied automatically by a client program and then shown to the user. But that just doesn't seem very elegant to implement, nor does it appear the uncensoring mask technique would be more useful than just serving the uncensored image itself. That's really the only way I could see having a separate file be useful as far as having an "automated method" goes. If a user has to manually apply the mask themselves using a third-party program, I don't think it will readily catch on. Part of the reason no one uses Gmask anymore, I think, is that it's a pain to open each file, select the small censor, find the correct filter, and re-save. That quickly becomes annoying, and thus discourages continued use.
I think your algorithm is really cool, because it allows an artist to make any kind of censorship reversible, not just a specific filter ala Gmask. But I don't think a user would willingly go through the trouble of downloading and applying an uncensoring mask for each image he downloads, nor do I think an artist would be willing to go through the trouble of generating them and sharing them. It quickly stops being automated once you require manual intervention like that. It also doesn't make sense to me that an artist would both require that 1) the image and mask be separate files distributed through different channels, and 2) that the uncensored image itself can't just be shared over the second channel and thus bypass the need for additional software. Maybe I need this explained more clearly.
I think what would make your algorithm truly useful is if the mask could somehow be embedded into the image covertly, and in a way that the artist has plausible deniability if it were discovered that he were sharing an uncensored version of his artwork. He wouldn't, technically, be sharing the uncensored images, just two pieces that when put together in the right way reveal the uncensored image. It's then simple to have, for example, a Photoshop plug-in to embed the mask in the file and an xnView plug-in to detect and apply the hidden mask automatically when the image is viewed. Ideally, the image would render properly (censored) in a browser or standard viewer, and would be totally compliant with whatever file format were used to encode the image, but only with a special viewer (or a viewer with a special plug-in) would the hidden mask be detected and applied, thus revealing the uncensored image. The whole time, the artist was technically not sharing the uncensored image, just the parts necessary for a special viewer to reconstruct it. This is possible so long as an image format supports arbitrary-length application-specific metadata. It need not even be auxillary color channels. JPEG supports application-specific header data, I know. I believe PNG does as well, or could perhaps be exploited a bit to do so (e.g., adding image data after the end-of-image marker). One simply need stuff an extra image (the mask) in the metadata, and voila. Now you just need one plug-in to write and one plug-in to detect such images. A plug-in only needs to be installed one time, and could be designed such that the user need make as little a change to their normal behavior as possible. That is certainly much more convenient, and thus much more likely to catch on, than requiring an artist to create a mask for every image, upload it to a secondary image dump site, and somehow tie it to the censored image, or a user to download and apply the mask for every image they want to see uncensored.
Sorry for the wall of text! I'm legitimately interested in the development of a way to circumvent censorship laws legally and easily in places where doing so is difficult, so I somehow felt the need to run my stupid mouth over multiple paragraphs to try to make a point. If you're interested, though, and I didn't sound like a rambling retard just now, I would be interested in developing something like this with you. We could talk about it more, maybe. If you're interested, of course. i am C porgrammer btw lol
>if distributing the mask through the same channel as the image itself would be problematic, and thus an alternate distribution channel is necessary, why not just share the uncensored image itself over said alternate distribution channel instead of the uncensoring mask? I could understand that being useful maybe if someone lived in a country where posting uncensored pornography was illegal, and said person wanted to post an image to some site where sharing the mask was prohibited as well, then the person could share the mask through a separate distribution channel and be in the clear, but that seems a bit convoluted. Plus, that doesn't seem very "automated" to me -- having to download and apply a mask manually.
A few things.
1. Distributing full uncensored images would require securing the secondary distribution channel from unauthorized use, which is inconvenient to the artist. Instead, this method allows the 'piggyback' image security from the primary channel, by allowing the diff files to be distributed freely.
2. The method is automatic in relation to its ability to transform a destructive mask, not that the mask is removed automatically without user input. Forcing some level of end-user input beyond simply clicking an executable or loading a single image is necessary to establish that they have full knowledge of what the application will do when they put the two images together in it. For implementations which aren't likely to be accepted in the typical mainstream venues these days, GMASK provides image metadata for autoselection embedded in the image. Probably as a result of its legal history, you still have to choose the relevant unmasking button(s) yourself.
3. There is no plausible deniability for distributing the DrMosaic method's diff file within the JPEG metadata, just as there is no plausible deniability when utilizing a mask generated by GMASK. The reason is because it is obvious to anyone moderately technically inclined what the mask is, and similarly if this method of mask transformation catches on, it would also be obvious as to its use, as both kinds of masks are visual in nature, and not strictly data-oriented. (This is to allow for loss of quality in transit, ie: lower quality JPG recompression from the primary distribution channel.)
When first presenting this method to a few of my peers before attempting to code it publicly, the main arguments made against it were that it is relatively inconvenient to the user, and rather pointless to the artist. The purpose of the program is not to be convenient to the user, but instead to be convenient to the artist, to satisfy in principle the notion that "uncensored" originals can be acquired without the artist having to actively maintain a secondary distribution channel for it. They simply put diffs up anywhere such images can be hosted legally, and forget about it. There is no steganography or trickery involved, which is important for avoiding potential legal issues with the primary distribution channel (or even the secondary distribution channel).
It is the responsibility of the user, if they wish to modify the images they purchased or have, to do so. Whether or not this poses an inconvenience is not so much my concern as it is that it is theoretically possible for any non-artistic user to do so, if they are at least reasonably technically-inclined. A commandline tool or image viewer which incorporates the method is all that would be needed. I would contrast this against the current state of most works on mainstream distribution sites like DLSite, where this ability doesn't even exist at all. (More direct methods to provide a reversible mask are obviously banned, as well.)
A few things.
1. Distributing full uncensored images would require securing the secondary distribution channel from unauthorized use, which is inconvenient to the artist. Instead, this method allows the 'piggyback' image security from the primary channel, by allowing the diff files to be distributed freely.
2. The method is automatic in relation to its ability to transform a destructive mask, not that the mask is removed automatically without user input. Forcing some level of end-user input beyond simply clicking an executable or loading a single image is necessary to establish that they have full knowledge of what the application will do when they put the two images together in it. For implementations which aren't likely to be accepted in the typical mainstream venues these days, GMASK provides image metadata for autoselection embedded in the image. Probably as a result of its legal history, you still have to choose the relevant unmasking button(s) yourself.
3. There is no plausible deniability for distributing the DrMosaic method's diff file within the JPEG metadata, just as there is no plausible deniability when utilizing a mask generated by GMASK. The reason is because it is obvious to anyone moderately technically inclined what the mask is, and similarly if this method of mask transformation catches on, it would also be obvious as to its use, as both kinds of masks are visual in nature, and not strictly data-oriented. (This is to allow for loss of quality in transit, ie: lower quality JPG recompression from the primary distribution channel.)
When first presenting this method to a few of my peers before attempting to code it publicly, the main arguments made against it were that it is relatively inconvenient to the user, and rather pointless to the artist. The purpose of the program is not to be convenient to the user, but instead to be convenient to the artist, to satisfy in principle the notion that "uncensored" originals can be acquired without the artist having to actively maintain a secondary distribution channel for it. They simply put diffs up anywhere such images can be hosted legally, and forget about it. There is no steganography or trickery involved, which is important for avoiding potential legal issues with the primary distribution channel (or even the secondary distribution channel).
It is the responsibility of the user, if they wish to modify the images they purchased or have, to do so. Whether or not this poses an inconvenience is not so much my concern as it is that it is theoretically possible for any non-artistic user to do so, if they are at least reasonably technically-inclined. A commandline tool or image viewer which incorporates the method is all that would be needed. I would contrast this against the current state of most works on mainstream distribution sites like DLSite, where this ability doesn't even exist at all. (More direct methods to provide a reversible mask are obviously banned, as well.)
Comments