As a KS backer of Light Table I always get sad about what might have been[1] if they hadn't gone the YC + VC route that basically lead to abandoning LT before it was near ready for daily use for most of us.
We never did get to see the vision that was presented in that KS...
[1] 2012 was two years before Brackets/Atom and three before VSCode.
They were not talking about through-hole LEDs in that section as Alps styles switches (Matias is resurrection of the simplified Alps style) cannot have both a through-hole LED and have a tactile or click leaf. They are talking about how Matias used a transparent switch housing along with SMD RGB LEDs which allow the light to shine through.
Yes, that is the one-line throw away dismissal of the whole affair if you innately believe that everything we do will always devolve to the status quo.
I reject this form of behavioral nihilism and prefer to believe that ideas can exact change in this world[1] and move people up and out of the status quo, and lament the failure of even efforts I think were doomed from the beginning.
[1] Which isn't to say I reject the notion that a large portion of people are just out to get theirs and to hell with the rest
I find it sad (but not at all surprising) that this is the state of the Bitcoin community. The level of discourse for what is supposed to be a technology that is billed as "liberating money from the whims of governments" has neatly conformed to exactly that of the current state of political discourse. Everyone who disagrees with you is a shill/troll or an idiot. Adding math and "decentralization" doesn't magically prevent humans from being humans.
I'm sure given just enough time the "community" will structure itself into a perfect replica of a modern bureaucracy.
edit: I'm not just extrapolating from this one post a gander over at /r/btc or /r/bitcoin shows the same lovely trend
Great to see a more generic pure-.NET image processing library. When I was doing this 5 years ago we basically had AForge.NET which was focused more on correctness of algorithms than speed. I tried to leverage that, but instead ended up with a totally custom image processing pipeline instead -- oh the battles with the GC and unsafe code...
Out of curiosity what is your overall vision for the library? Are you looking for a System.Drawing high-level API or more of an OpenCV-like low-level API?
It's not just that, it's also the people who want to trot out "hur hur hur, only uneducated people voted for Trump"
I'm just so sick of all the navel gazing going on between the Bernie or Bust'ers, the Establishment Dems, the NeverTrumps, the Pro-Trumps, the Libertarians, and on and on and on.
Every last one of them is pushing some absurdly reductionist hot take argument in their bubbles and papering over the real issues plaguing people.
Could be, but personally I'm done with being silent and just chuckling silently to myself or rolling my eyes when people pull out these infotainment zingers disguised as "insight".
The last year has ripped covers off the culture war that the US has been slowly boiling in like a frog. BLM and Trump aren't one offs, there are tons of people with serious gripes in this country, and for myself I'd rather call out the BS that obscures this than just sit here and let it stand unchallenged.
That is such an absurd and reductionist dismissal of this election that is no different than the equally wrong people saying "59 million people liked all the old sexist, homophobic, racist and xenophobic attitudes, and 59 million other people didn't"
What you are doing here is just perpetuating the problems that have plagued this election cycle and made it so people are completely unable to discuss real issues.
The hardest part of an open source poll would be anonymization. Demographic information in some areas could be enough to come pretty close to uniquely identifying an individual.
The rest of it: Likely Voter Models, Demographic Weighting, etc would be pretty easy to have open source and reproducible once you've solved the issues.
I for one am thankful for Jest and Yarn. I recently switched over to Jest and I love most everything about it and the built in watch with caching reduces friction immensely (now if we can just allow custom preprocessors to return promises that would make life easier for integration of things like rollup). And yesterday I flipped over to using yarn and it definitely solves most of my pain points with npm.
So yeah, I'm definitely on the "keep reinventing" side of this debate.
It's much more nuanced than that though. Increasing the evaporation rate also makes exploitation much harder, not to mention that the positive feedback cycle on previously very good edges can take a long time to dissipate.
ACO for dynamic environments generally require much more attention to how the problem is applied to the environment or the generation of a more hybrid approach.
One of the biggest drawbacks with things like ACO (ant colony optimization) are actually more in dynamic environments rather than static ones like these. Pheromone trails tend to reinforce the information from the old topology rather than the new topology and you need to add more wrinkles to the algorithm to better adapt to a changing environment.
When it comes to static problems like TSP, the translation of the problem has a lot of influence on how likely the heuristic is to fall into local optima. For instance in the case of ACO you have pheromone trails that are intended to dissipate faster as the distance between food increases. When translating something like TSP you have a decision to make: you can go literal and use the physical distance between edges on a graph (causing closer nodes to be more heavily weighted). Or you could use the total distance of the circuit (causing edges that occur in better solutions to be more heavily weighted). Or you can blend them both -- which is what it looks like the author did.
These algorithms are heuristics and are not intended to necessarily give you the "best" answer, but to get you a "pretty good" answer on messy problems that don't neatly fit into a problem that has been heavily researched like TSP.
Excellent. It's a little funny how when you start problems like these you start becoming an expert in fields you never thought you'd have to play in like color spaces, color perception theory, etc.
Great work, and I look forward to seeing future posts on the solutions you've been able to come up with!
On the contrast topic: adaptive thresholding can be very helpful (I believe Bradley Local Thresholding was one I had particular success with) however most of these algorithms work in a grayscale domain which means they are dependent upon which color->grayscale transformation is used[1]. I spent a long time researching full color algorithms but never got to a truly successful end result with them. And even if you get a good image with huge contrast you still will end up with the actual light/dark transition looking like an edge.
On 3D deformation, you're officially in academic research land. Nearly all algorithms require you to have a solid guess as to what the aspect ratio of the target object is. Other algorithms use heuristics based upon what you expect to find on a page. One particularly fun algorithm used the baseline of text (I believe for that paper it was Arabic) and fit a high-order curve to it which was then reversed. Unfortunately I haven't seen a truly generic approach that doesn't require a implementation-specific input.
[1] Frankly my feeling is that RGB to grayscale is a mistake and holding back many of these algorithms
It's definitely happening on the device. Document recognition like this moved onto the device about 3 years ago, and in fact if they didn't do this device side they would have a harder time dealing with the Mitek patents[1] that are in this space.
The actual OCR and data extraction likely occurs on the server side, but the document recognition on device is a much better user experience.
[1] USAA and Mitek were suing each other over the patents from 2012-2014.
Having worked with several of the commercial products in this space almost all of them lean on OpenCV for the hard parts, and I'd be surprised if this didn't either.
Worked on this problem exactly 2-3 years ago (developed automated document processing in the accounts receivable and accounts payable sector for a decade plus). It's a fun iceberg problem that looks simple on the surface but tends to have some real thorns the deeper down you go.
Document identification like this is unfortunately the "easy" (and it's not particularly easy to do real time) part. The next two steps involve 3D de-deformation since unlike a flatbed scanner you cannot assume the paper is actually completely flat -- imagine a previously folded page, etc.
I love this stuff as it is at a crossroads of a half dozen different disciplines. Lots of money to be had if this can be done is a really robust manner.
Edit:
A couple examples of why this gets really hairy really fast:
* You'll notice that all the documents are shown on a high contrast background (dark wood grain) without a lot of stark lighting. One of your first steps in edge detection and line identification is image segmentation to remove background from foreground and then start removing noise. If you have a white piece of paper on a white table, or a large lighting contrast (say from an open window casting daylight on half the page) it really wreaks havoc with the algorithms.
* Imagine you're trying to recognize a page from a text book in the middle of the book. The way the page lies you end up with non-rectangular pages (they curve due to the spine) which kills the hough line transformation (there are also hough circle algorithms, but you get the point) and the rectangle selection.
We never did get to see the vision that was presented in that KS...
[1] 2012 was two years before Brackets/Atom and three before VSCode.