| >>93643 OK, well that is AI anime art generation. I'm not sure if it supports image input. plus it's like 50GB of downloads. I think we can do this with less in flash. What we are going for will be Less AI and More user input from a base medium (image/video). We'll start with code for images, and work up to gifs and then videos with encoded sound. From reviewing the basic documentation on the supplied AI generators, they fuction off of models of a wide array of characters, these are likely prerendered user created art assets from like 32x32 angles per body part. thus the AI just has to indentify the assets closest to the art style and closest to the character input and slap them on, then do background cleanup. We will be leaving some of these operations to the user and allowing users to create profiles from existing art assets. we'll likely include less draw styles. Lets go through the logic of our set-up. 1: flash will need a simple textbox for file location input, and a button which takes the text from the textbox and tries to load the image via the AS3 Image() module.
https://help.adobe.com/en_US/FlashPlatform/refere nce/actionscript/3/spark/components/Image.html
2: we will get the image's pixel data via the bitmapData property of the Image() module, this is read only.
3: using the bitmapData as a reference we begin planning via more user input these input will define Colors such as:
3.1: Brightest specular (light reflection) color of skin in Hexidecimal color code.
3.2: Mid range Average of skin color in Hexidecimal color code.
3.3: Darkest shadow color of skin in Hexidecimal color code.
3.a: Using this input data our code will be able to ROUGHLY Indentify regions of skin based on any color in that range. It'd be best to describe this change as a gradual curve rather than a linear change.
3.b: this data will also grant our code the ability to scale this Gradient based on the number of pixels width of a potential skin region. 4: potential skin regions, in order to do this the user will have to add some more color definitions.
4.1: For each different colored clothing the user wants to remove they will need the hexidecimal color code of the brightest specular (light reflection) point for each color present on the clothing. (multiple inputs)
4.2: the median average color for each different color on the clothing. (multiple inputs)
4.3: the darkest shadow color for each different color of the clothing. (multiple inputs)
4.a: this produces a method for the code to ROUGHLY identify the clothing. 5: Line color definitions.
5.1: the lightest color line
5.2: (Optional) an average median color for the lines
5.3: the darkest color line
5.a: this supplies yet more data to the code to ROUGHLY determine where and how thick the lines are. depending on the picture it may require multiple line color definitions.
5.b: it supplies a color scale and gradient for drawing of new lines. 6: Hair Identification.
6.1: the brightest specular color of the hair.
6.2: the average hair color
6.3: the darkest hair shadow color.
6.a: this will allow the software to ROUGHLY detect the hair in the image, this step may be Optional as it's only necessary where the hair would overlap the character's chest or pelvic region and you do not want it removed with the clothes!
6.b: it specifies a gradient range of colors in pixels which unless surrounded by clothing color will be marked to "not over write" with skin color gradients. So far in 3, 4, 5 and 6 "ROUGHLY" indicates that logically speaking it should be correct, however it does not take into effect other areas of the image! more often than not, especially in a Color Indexed image you are likely to have the same colors on the skin or clothing reused or also present in the hair, eyes, lines, and background et cetera. This means that if our current ROUGH information were visualized as a pixel selection, yes the clothing/skin would be selected, but you'd also find that random sections of non-clothing/non-skin are being selected in they hair, eyes, and background etc. It also does not take into account multiple characters in an image. To fix this we are going to need yet more user input. (normally this would all be done with AI, but that will be a lot of complex geometrical probability math. yeah.. no.) So user input is king here. What I've devised is as follows: Ragdoll: we will develop a coded flash curve ragdoll character model which can be moved, 3D rotated (only AS3 can do this), and scaled in-game. The model will be split into different curve regions as separate shapes/symbols which are all connected together in code from rotation points at the joints etc. each object must be able to 3D rotate independently of each-other whilst staying connected. and each peice should be able to be user controlled to Arrange>forwards or Arrange>backwards in the frame. it likely wont need a head just torso and legs and arms. The ragdoll should be transparent to allow the player to see the image behind it. This ragdoll should be placed exactly over the character in the pose required. and from this Code will be used to get the scaled proportions of each piece in relation to the pixels they overlay in the image.
This supplies the Fix for our "ROUGHLY" issue as it defines the area of the image to be overwritten.
The width and angle of each piece of the ragdoll will also provide valuable information for the angle of the gradients to be drawn at and the number of pixels from side to side etc. as well as the 3D angle to define what is closer or further from the screen.
Lastly the Arrangement of pieces of the ragdoll (whether they are behind or in front of other pieces) will determine draw calculation order. starting to draw from the back most pieces and then working towards the front. The Pose (individual part scale and angle) of the ragdoll can be recorded as part of the profile for an image, this Pose profile can be used to compare Keyframes of an animation in example. that's for going forwards towards nudifying animations. I'm guessing more controls will be necessary for the ragdoll over time, looking forwards: clicking a body part and pressing a hotkey like H for "hide" could mark it as not being calculated as a piece to be drawn over. Nipple and pussy locations, drawtypes/style and scales will also be needed as modifiables on the posedoll, likely with some default already there with multiple symbols to describe the different regions labia majora, labia minora, nipple top, nipple side, areola left, right etc. and likely a selection window for the type of nipple etc. the user wants to have drawn. the User set-up would be alot but once set-up it could be applied to multiple frames with just a few edits to the ragdoll pose and scale/arrangement of pieces. the color profiles would not need editing. FINALLY, https://help.adobe.com/en_US/FlashPlatform/refere nce/actionscript/3/flash/display/BitmapData.html This allows rewriting of an images pixel data IN FLASHGAME MEMORY. "You can also access the BitmapData for a bitmap image that you load with the flash.display.Loader class." once getting all the calculations of pixel change is done and kept in memory, you can then use the BitmapData.applyFilter() method to apply the changes to the bitmap image. for an animation or video you'd likely have to break the video down into image frames and include a timeline seeker with a textbox for frame number. to save the entire bitmap to an output image (at a user input file location, with a submit Button) code as follows should work.
//SAVE
_MyBitmap = Bitmap(the bitmap data);
var jpg:JPGEncoder = new JPGEncoder(100);
var ba:ByteArray = jpg.encode(_MyBitmap.bitmapData); _fs.open(_f, FileMode.WRITE);
_fs.writeBytes( ba, 0, ba.length );
_fs.close(); I hope this logic helps describe the construction. | 
