final post 04/17/2014
well, the project has come to a close. i've officially given my presentation and have what i consider to be a final project. while the powerpoint presentation (found on this website's homepage) goes into more detail about what could have been better, to restate here:
•Global Variables*
•BIG Files*
•Color Leakage
•Thickening Detected Edges
•Post-Edge Noise Reduction
•Already Low-Quality Images
any of these would be quite easy to correct given a tad bit more time. global variables are inevitably a result of my laziness; i list big files only due to the extra time required for them; in some photos it would certainly add to the cartoon-feel of the photo were there thicker edges; in others the scattered noise and "debris" is a bit much; and finally, dealing with low-quality images is difficult when using color quantization (i.e. give a low-quality image to a program supposed to make an image of lower quality and, yup, it doesn't turn out so well).
i'm satisfied with the results. i image, if i find the time, i might very well work further on this project. for now, it's been a fun ride and i'm grateful for the opportunity.
~miles
well, the project has come to a close. i've officially given my presentation and have what i consider to be a final project. while the powerpoint presentation (found on this website's homepage) goes into more detail about what could have been better, to restate here:
•Global Variables*
•BIG Files*
•Color Leakage
•Thickening Detected Edges
•Post-Edge Noise Reduction
•Already Low-Quality Images
any of these would be quite easy to correct given a tad bit more time. global variables are inevitably a result of my laziness; i list big files only due to the extra time required for them; in some photos it would certainly add to the cartoon-feel of the photo were there thicker edges; in others the scattered noise and "debris" is a bit much; and finally, dealing with low-quality images is difficult when using color quantization (i.e. give a low-quality image to a program supposed to make an image of lower quality and, yup, it doesn't turn out so well).
i'm satisfied with the results. i image, if i find the time, i might very well work further on this project. for now, it's been a fun ride and i'm grateful for the opportunity.
~miles
crunch time 04/17/2014
i'm beginning to learn that this project has less to do with what i can personally create and instead how well i can incorporate what has already been created.
the sobel implementation is entirely satisfactory for my purposes. though, the recursive color simplification algorithm is ungodly slow...no good if we're aiming for real-time adjustments of the final product.
that being said, i've snooped across the internet and discovered what should have been my starting point 3 months ago...i suppose that's the way it goes. have to mess up a hundred times before succeeding once.
color quantization. this is what dr. pankratz hinted toward in the beginning, in so many words. it's typically used for cutting down file size by discretely bucketing image colors into a more simplified palette. for our purposes, we'll be a little less discrete and a little more buckety (term coined here for the first time).
i've discovered a super sleek algorithm (http://www.codeproject.com/Articles/66341/A-Simple-Yet-Quite-Powerful-Palette-Quantizer-in-C)...it allows for various methods of quantization. i'll be narrowing it down to a "median cut" algorithm, in which each pixel in the photo is accounted for, fanned out across an x-axis, and then intervals are taken from there, depending on how many colors one wants.
the amount of colors desired is an option i'll leave up to the user. right now 8 and 16 seem to be rendering the photo most "cartoony." one problem is the inevitable loss of vibrant colors; in the dumbing down of the median cut algorithm, if there's a small patch of bright red, the algorithm shows NO MERCY. if i have time, i may consider ways to overcome this problem. otherwise, i think we can live with the result.
the next question is how to sort through all the code, which is currently downloaded as a perfect, working project. i'll want to extract only specific elements and then combine them with the sobel code. unfortunately this all means i'll probably be abandoning my original color simplification code entirely, the code that took me days and days and days and days (ad infinitum). alas, all part of the process.
the next move then is to combine this new-fangled code with the sobel, and finally to determine what options should be available to the user. as it stands, i intend to give them the ability to adjust the line detection sensitivity and amount of colors in the palette. should be good.
~miles
i'm beginning to learn that this project has less to do with what i can personally create and instead how well i can incorporate what has already been created.
the sobel implementation is entirely satisfactory for my purposes. though, the recursive color simplification algorithm is ungodly slow...no good if we're aiming for real-time adjustments of the final product.
that being said, i've snooped across the internet and discovered what should have been my starting point 3 months ago...i suppose that's the way it goes. have to mess up a hundred times before succeeding once.
color quantization. this is what dr. pankratz hinted toward in the beginning, in so many words. it's typically used for cutting down file size by discretely bucketing image colors into a more simplified palette. for our purposes, we'll be a little less discrete and a little more buckety (term coined here for the first time).
i've discovered a super sleek algorithm (http://www.codeproject.com/Articles/66341/A-Simple-Yet-Quite-Powerful-Palette-Quantizer-in-C)...it allows for various methods of quantization. i'll be narrowing it down to a "median cut" algorithm, in which each pixel in the photo is accounted for, fanned out across an x-axis, and then intervals are taken from there, depending on how many colors one wants.
the amount of colors desired is an option i'll leave up to the user. right now 8 and 16 seem to be rendering the photo most "cartoony." one problem is the inevitable loss of vibrant colors; in the dumbing down of the median cut algorithm, if there's a small patch of bright red, the algorithm shows NO MERCY. if i have time, i may consider ways to overcome this problem. otherwise, i think we can live with the result.
the next question is how to sort through all the code, which is currently downloaded as a perfect, working project. i'll want to extract only specific elements and then combine them with the sobel code. unfortunately this all means i'll probably be abandoning my original color simplification code entirely, the code that took me days and days and days and days (ad infinitum). alas, all part of the process.
the next move then is to combine this new-fangled code with the sobel, and finally to determine what options should be available to the user. as it stands, i intend to give them the ability to adjust the line detection sensitivity and amount of colors in the palette. should be good.
~miles
sobel + colorizing merged 04/08/2014
well, i guess we call this result number.
pretty hideous, all things considered (and i mean that as no slight to dr. pankratz) i'm not even sure how much color correction is be done via the recursive algorithm? it seems that the majority of color changes have stemmed from the original "color bucketing" process. not to mention the massive amount of time it takes.
even though, i have mechanisms in place to thin the lines up, to use less lines, etc, but real-time changes like those are no good if the color algorithm takes a week to complete.
i've ditched my averaging technique, apparently misinterpreting it as the culprit for slow speeds. nope. something else. probably the fact that every single pixel goes through extensive recursive checks (-_-).
the good: the black lines are laid over the top before color processing even takes place. that means that color checking passes over what's already black, and that's a quickie quick algorithm.
the bad: while i've rid groups from the whole shabang, my plan to instead convert each bordering pixel into its calling pixel doesn't seem to be having much effect.
may be time for a meeting with the profs!
~miles
well, i guess we call this result number.
pretty hideous, all things considered (and i mean that as no slight to dr. pankratz) i'm not even sure how much color correction is be done via the recursive algorithm? it seems that the majority of color changes have stemmed from the original "color bucketing" process. not to mention the massive amount of time it takes.
even though, i have mechanisms in place to thin the lines up, to use less lines, etc, but real-time changes like those are no good if the color algorithm takes a week to complete.
i've ditched my averaging technique, apparently misinterpreting it as the culprit for slow speeds. nope. something else. probably the fact that every single pixel goes through extensive recursive checks (-_-).
the good: the black lines are laid over the top before color processing even takes place. that means that color checking passes over what's already black, and that's a quickie quick algorithm.
the bad: while i've rid groups from the whole shabang, my plan to instead convert each bordering pixel into its calling pixel doesn't seem to be having much effect.
may be time for a meeting with the profs!
~miles
hell for heaven 03/31/2014
i haven't posted in some time.
mostly because i haven't done anything in some time.
well, it's not that i haven't tried; i've been stuck burning through manuals on openCV and emguCV, callousing my fingers, bleeding out through my eyes.
only to find a much quicker solution: a sobel based line detecter by Damian Wegner (http://compsci02.snc.edu/cs460/2005/wegndt/)
i learned a lesson i've already learned, forgotten, learned, and forgotten: understand what you're doing before you do it...
during the process of decoding Wegner's Visual Basic code into C#, i never took the time to understand. just robot-converted until i wanted death. as i attempted implementation, i had no idea what any of it did. after the most frustrating day in weeks, i found over half his code to be superfluous ( -_- ) and i tossed it aside.
what's left is, i must say, some damn good stuff. a demo below of a line detection rendering of an old photo
i haven't posted in some time.
mostly because i haven't done anything in some time.
well, it's not that i haven't tried; i've been stuck burning through manuals on openCV and emguCV, callousing my fingers, bleeding out through my eyes.
only to find a much quicker solution: a sobel based line detecter by Damian Wegner (http://compsci02.snc.edu/cs460/2005/wegndt/)
i learned a lesson i've already learned, forgotten, learned, and forgotten: understand what you're doing before you do it...
during the process of decoding Wegner's Visual Basic code into C#, i never took the time to understand. just robot-converted until i wanted death. as i attempted implementation, i had no idea what any of it did. after the most frustrating day in weeks, i found over half his code to be superfluous ( -_- ) and i tossed it aside.
what's left is, i must say, some damn good stuff. a demo below of a line detection rendering of an old photo
there are sensitivity controls i intend to learn how to operate better. and i'll need to determine a way to get rid of all the miniscule lines...
emgu CV/openCV 03/05/2014
all the goodies i need seem to be located in the prized openCV library, created in the late 90s by intel for some fancy image manipulation algorithms.
since openCV is c++ based, i'm downloading emgu CV, which is basically openCV manipulated to comply with c# and the .NET framework.
one function in particular looks particularly helpful, found here: http://docs.opencv.org/modules/imgproc/doc/feature_detection.html#matas00.
a sample pic of the sort of progress we'd expect:
all the goodies i need seem to be located in the prized openCV library, created in the late 90s by intel for some fancy image manipulation algorithms.
since openCV is c++ based, i'm downloading emgu CV, which is basically openCV manipulated to comply with c# and the .NET framework.
one function in particular looks particularly helpful, found here: http://docs.opencv.org/modules/imgproc/doc/feature_detection.html#matas00.
a sample pic of the sort of progress we'd expect:
this seems ideal and hopefully I can get it working without too many problems. here, the hope would be to transform all white lines into thicker black lines but leave the original picture otherwise untouched, then run the algorithm as it otherwise stands.
hough transform 03/03/2014
dr. pankratz and i discussed two improvements to implement in the current program:
1. simplify the color base. this i've done via a simple Math.Ceiling function which places each RGB value into the nearest 64th. this simplifies the palette and the final product is closer to what we desire.
2. line detection. there seems to be a well-known algorithm called the "Hough Transform" which I'm researching further. the hope would be to run this on the photo before any color changes and, once lines are detected, thicken them and perhaps places bools (e.g. bool IsLine = true) on line pixels to be avoided during next scan. i imagine, once this is successfully implemented, great improvements will be seen in the quality of the picture.
dr. pankratz and i discussed two improvements to implement in the current program:
1. simplify the color base. this i've done via a simple Math.Ceiling function which places each RGB value into the nearest 64th. this simplifies the palette and the final product is closer to what we desire.
2. line detection. there seems to be a well-known algorithm called the "Hough Transform" which I'm researching further. the hope would be to run this on the photo before any color changes and, once lines are detected, thicken them and perhaps places bools (e.g. bool IsLine = true) on line pixels to be avoided during next scan. i imagine, once this is successfully implemented, great improvements will be seen in the quality of the picture.
first algorithm finished...good news (and bad news) 02/24/2014
since i began initial design of a rudimentary cartoonizing algorithm last thursday, i've poured over paper and Visual Studio alike during the intermittent days...
surprising, less problems arose than i would have expected; proper planning on scratch paper really slowed down the process to a comprehensible speed (aka YOU sure as hell won't be able to understand my code, but i do...i do very well)
without further ado, our first "result"
since i began initial design of a rudimentary cartoonizing algorithm last thursday, i've poured over paper and Visual Studio alike during the intermittent days...
surprising, less problems arose than i would have expected; proper planning on scratch paper really slowed down the process to a comprehensible speed (aka YOU sure as hell won't be able to understand my code, but i do...i do very well)
without further ado, our first "result"
not bad for a first go, hmmm??? you must remember, only one, got it, ONE algorithm was borrowed here! the rest? entirely of my own design (that's pride speaking).
the second pride takes the stage, it's nice to have him immediately confronted by shame...notice that little run time there at the bottom? i do...a lousy 1minute and 40seconds. by the time my app has finished cartoonizing your photo you've already disinterestedly deleted it in favor of some mindless tweet about siri conversations.
time, however, is something i believe we can cut down. as far as the rest of the algorithm is concerned, i have yet to take the time trying to 'better' it...for now, i will rest in this good, good progress.
cheers,
miles
the second pride takes the stage, it's nice to have him immediately confronted by shame...notice that little run time there at the bottom? i do...a lousy 1minute and 40seconds. by the time my app has finished cartoonizing your photo you've already disinterestedly deleted it in favor of some mindless tweet about siri conversations.
time, however, is something i believe we can cut down. as far as the rest of the algorithm is concerned, i have yet to take the time trying to 'better' it...for now, i will rest in this good, good progress.
cheers,
miles
comparison algorithm 02/21/2014
i believe i've just caught myself (though, perhaps 3 hours too late) venturing down a dark, dark path, unsure why i began the march in the first place. i've gotten a hold of something that may turn out to be quite useful: a somewhat simple algorithm determining "likeness" between two pixels that works with 'perceived color' as opposed to simply RGB values. now, i'm not sure what that means, but following a few tests, RGB{255, 255, 255} comes up as worlds apart from RBG{0, 0, 0}. the source code (written in java, which i've converted into C#, because i'm an intelligent growing man), was found here: http://www.compuphase.com/cmetric.htm
yesterday i wrote out two pages worth of (enigmatic) pseudo-code i intend to soon attempt implementing. for now i'm being extra meticulous, trying to anticipate any problems before typing up the goodness (perhaps an impossible feat).
i believe i've just caught myself (though, perhaps 3 hours too late) venturing down a dark, dark path, unsure why i began the march in the first place. i've gotten a hold of something that may turn out to be quite useful: a somewhat simple algorithm determining "likeness" between two pixels that works with 'perceived color' as opposed to simply RGB values. now, i'm not sure what that means, but following a few tests, RGB{255, 255, 255} comes up as worlds apart from RBG{0, 0, 0}. the source code (written in java, which i've converted into C#, because i'm an intelligent growing man), was found here: http://www.compuphase.com/cmetric.htm
yesterday i wrote out two pages worth of (enigmatic) pseudo-code i intend to soon attempt implementing. for now i'm being extra meticulous, trying to anticipate any problems before typing up the goodness (perhaps an impossible feat).
SUCCESS STORY #1 (more to come?) 02/19/2014
over the past week i've been exploring C# with the help of a mr. cory hahn and dr. bonnie mcvey. having never graduated from a 350 course, i've been in the dark. a couple labs later and my confidence has grown to a visible speck of light.
i've spent much of today adapting dr. mcvey's "convert to black and white" program to a very simple program designed to cycle through a photos pixels and average every 5x5 area. thus, for a 200x200 photo, the program ought to create a 'blur' effect, segmenting the photo into 5x5 single-colors portions.
after much fiddling [many failures...1) miscalculating the required size of an 'averaging array' 2) misunderstanding the format of the array i'm working with)], i finally came up with a final product i'm quite proud of. the final product should look something like this (errr... exactly like this):
over the past week i've been exploring C# with the help of a mr. cory hahn and dr. bonnie mcvey. having never graduated from a 350 course, i've been in the dark. a couple labs later and my confidence has grown to a visible speck of light.
i've spent much of today adapting dr. mcvey's "convert to black and white" program to a very simple program designed to cycle through a photos pixels and average every 5x5 area. thus, for a 200x200 photo, the program ought to create a 'blur' effect, segmenting the photo into 5x5 single-colors portions.
after much fiddling [many failures...1) miscalculating the required size of an 'averaging array' 2) misunderstanding the format of the array i'm working with)], i finally came up with a final product i'm quite proud of. the final product should look something like this (errr... exactly like this):
while this is only a small start, it IS in fact a start.....
next step is to work with edge-detecting functions and determining whether or not i can combine methods.
a side note, i've successfully uploaded a "hello world" program to the Android phone through eclipse. after a week of accomplishment, sweet sweet sleep.
goodnight, friends.
~miles
next step is to work with edge-detecting functions and determining whether or not i can combine methods.
a side note, i've successfully uploaded a "hello world" program to the Android phone through eclipse. after a week of accomplishment, sweet sweet sleep.
goodnight, friends.
~miles
rough outline 02/13/2014
after a brief meeting with DCP, i've come up with a short list of to-dos before next week:
~miles
after a brief meeting with DCP, i've come up with a short list of to-dos before next week:
- use function in C# to convert a simple, 200x200 pixel .bmp into an array and convert the result into grayscale
- explore "edge detection" functions (in a broad sense)
- learn to transport image from android phone to computer and vice versa; seek at (in DCP's words) a "blasting" function which instantly converts a .bmp into an array file
- get a better grasp on how images or stored into arrays
~miles
return to confidence 02/06/2014
while we'd already anticipate a roller coaster, actually experiencing the ride is another story entirely. from one day to the next I either crumble under the pressure of nagging anxiety or effortlessly subdue it with a forefinger of optimism.
a couple strides were made today, following our 11o'clock gathering of friends:
-as suggested by friends, in particular Quang, I'm going to have a go at C#. while I've never been formerly trained, C# is a close cousin to C++, my native language and land of comfort. I've checked out a helpful book from the library and intend to attempt a small test program per the book's references to get a feel for the environment.
-I've come up with some preliminary ideas for the process: I imagine for loops cycling through pixels, temporarily concatenating RGB values into a single value for comparison purposes. i'd then decide on a range that seems acceptable for "likeness" (which we could later alter with sensitivity controls). the program would then sift through each pixel, perhaps using a stack and check all pixels surrounding the currently selected pixel for their values. a bool would also be added (e.g. VISITED). the concept might look like this:
while we'd already anticipate a roller coaster, actually experiencing the ride is another story entirely. from one day to the next I either crumble under the pressure of nagging anxiety or effortlessly subdue it with a forefinger of optimism.
a couple strides were made today, following our 11o'clock gathering of friends:
-as suggested by friends, in particular Quang, I'm going to have a go at C#. while I've never been formerly trained, C# is a close cousin to C++, my native language and land of comfort. I've checked out a helpful book from the library and intend to attempt a small test program per the book's references to get a feel for the environment.
-I've come up with some preliminary ideas for the process: I imagine for loops cycling through pixels, temporarily concatenating RGB values into a single value for comparison purposes. i'd then decide on a range that seems acceptable for "likeness" (which we could later alter with sensitivity controls). the program would then sift through each pixel, perhaps using a stack and check all pixels surrounding the currently selected pixel for their values. a bool would also be added (e.g. VISITED). the concept might look like this:
while i only eyed up what looked alike in the above example, we still see signs of a simplification of colors...this, at least for now, is my goal: to simplify the color scheme of a given picture. later we can worry about shifting things around for a more abstract/surreal representation and obtaining the cartoony rotoscoping effect we all love so dearly
--------------------------------------------------------------------------------
in conclusion, i'm now going to tinker with some basic C# coding and search the internet for any bits of code already floating around accomplishing a similar task:
so far I've explored:
http://www.toonyphotos.com/rotoscope : a platform that misses the mark as far as automation goes...toonyphotos requires the user to manually etch out the edges they'd like to demarcate. the general idea isn't bad but, again, a painstaking, non-automated project which produces poor results (e.g:
--------------------------------------------------------------------------------
in conclusion, i'm now going to tinker with some basic C# coding and search the internet for any bits of code already floating around accomplishing a similar task:
so far I've explored:
http://www.toonyphotos.com/rotoscope : a platform that misses the mark as far as automation goes...toonyphotos requires the user to manually etch out the edges they'd like to demarcate. the general idea isn't bad but, again, a painstaking, non-automated project which produces poor results (e.g:
- i've just discovered the quintessential example of cartoon apps, an iTunes app called ComicBooth1...(a demo here: http://www.youtube.com/watch?v=u9Q0QuVFXKU) the capabilities are absolutely stunning and highly encouraging in regards to what I'll be capable of doing. I know iTunes is often stingy with source code but hopefully after searching around I can get a hold of something....
alas, dear reader, I've just accidentally installed a vicious virus in the name of Computer Science; the bugger has disabled my laptop's network adapter and frozen all attempts at progress.
let's pray for the efforts of Bill Gate's System Restore......
~miles
early anxiety 02/05/2014
dwelling on the impending difficulties of this assignment a bit too much...
i feel undereducated and incapable; I'm entirely unfamiliar with Android as well as Eclipse, and the hours I've so far spent seeking out a means to taming this wild beast have been fruitless.
my new plan is to CALM DOWN and seek comfort in the equally anxious blog entries of the Capstone's predecessors; Matthew Chouinard in particular attempted a similar project.
before any actual programming can begin, I must commit to a platform and learn the basics of whatever language I'll be using. while that seems to go without saying, it's easier said than done. my unfamiliarity with all of the seemingly superfluous code outlining Eclipse templates is incomprehensible; I've checked out an Eclipse book from the library, watched a couple Youtube tutorials, and attempted the startup techniques outlined by the Eclipse website though little has been gained. rather than running circles around this blog entry, i will now dive back into the abyss of programming mumbo jumbo...
dwelling on the impending difficulties of this assignment a bit too much...
i feel undereducated and incapable; I'm entirely unfamiliar with Android as well as Eclipse, and the hours I've so far spent seeking out a means to taming this wild beast have been fruitless.
my new plan is to CALM DOWN and seek comfort in the equally anxious blog entries of the Capstone's predecessors; Matthew Chouinard in particular attempted a similar project.
before any actual programming can begin, I must commit to a platform and learn the basics of whatever language I'll be using. while that seems to go without saying, it's easier said than done. my unfamiliarity with all of the seemingly superfluous code outlining Eclipse templates is incomprehensible; I've checked out an Eclipse book from the library, watched a couple Youtube tutorials, and attempted the startup techniques outlined by the Eclipse website though little has been gained. rather than running circles around this blog entry, i will now dive back into the abyss of programming mumbo jumbo...
proto-project 02/01/2014
Day 1 of the 3 month trek. Upon receiving permission from no one I've decided to make this page more engaging than any other. That may prove negative for you for my mind on paper sometimes leaves an unseemly and chaotic impression.
I've just received my project, tritely titled, "Cartoon App" from Dr. Pankratz. DCP shared concerns regarding my motivation which shook me, slapped me around, and then motivated me to not fail. I happen to like working with images and have a lifelong affinity for Photoshop. We're talking here about Rotoscoping, a beautiful technique incorporated in the infamous Chuck Schwab commercials and, my favorite film, Waking Life. Now, the technique when applied to film seems to be a tedious frame-by-frame artist rendering, though I know filters exist capable of bypassing the artist in favor of technology's most steady hand. We're going to get this puppy running via Android (on Android, for Android?), something profoundly new to me (the sole remains of the dying Dumbphone generation...). Ideas are already percolating, particularly the possibilities for the user interface and how to make the final product look crisp and sharp. Preliminary plans include learning how to migrate Eclipse software for Android programming and tinkering with previously designed programs employing the same general methodology. Now more excited than fearful, though we all know how short-lived that tends to be....Miles out.
Day 1 of the 3 month trek. Upon receiving permission from no one I've decided to make this page more engaging than any other. That may prove negative for you for my mind on paper sometimes leaves an unseemly and chaotic impression.
I've just received my project, tritely titled, "Cartoon App" from Dr. Pankratz. DCP shared concerns regarding my motivation which shook me, slapped me around, and then motivated me to not fail. I happen to like working with images and have a lifelong affinity for Photoshop. We're talking here about Rotoscoping, a beautiful technique incorporated in the infamous Chuck Schwab commercials and, my favorite film, Waking Life. Now, the technique when applied to film seems to be a tedious frame-by-frame artist rendering, though I know filters exist capable of bypassing the artist in favor of technology's most steady hand. We're going to get this puppy running via Android (on Android, for Android?), something profoundly new to me (the sole remains of the dying Dumbphone generation...). Ideas are already percolating, particularly the possibilities for the user interface and how to make the final product look crisp and sharp. Preliminary plans include learning how to migrate Eclipse software for Android programming and tinkering with previously designed programs employing the same general methodology. Now more excited than fearful, though we all know how short-lived that tends to be....Miles out.