One was a method of texting that didn't require looking at the phone, the other was a way to display lo-res graphics data without pixelation.
One was a method of texting that didn't require looking at the phone, the other was a way to display lo-res graphics data without pixelation.
Oh that's easy, every phone before iPhone could do it - you need a) a physical keyboard, and b) a soft real-time OS. Tactile feedback of physical buttons + stable UI configuration with learnable delays = you could learn to operate the phone without taking it out of your pocket.
:)
Joking aside, what was your invention? Could you link to the patent?
Patent 7812993 Lossy method for compressing images and video
Patent 7711748 Method and apparatus for simplified access to online services
Patent 7028033 Method and apparatus for simplified access to online services
Patent 6897977 Lossy method for compressing pictures and video
Patent 6850782 Wireless device with vibrational communication capabilities
Patent 6657647 Controlling the order in which content is displayed in a browser
Patent 6418323 Wireless mobile phone with Morse code and related capabilities
AFAIK, none of these have been made use of. Though every time I see banding and blockiness in video, I think "they should implement triangles!"
At the risk of forever poisoning myself for related work, I guess. Whose bright idea was with that "you look at it, and you and everyone you know is now liable for 3x more damages for accidental infringement" law?...
Mine, obviously. All my ideas are Bright ideas.
The patents may have expired, anyway. One of the reasons I did the patents was I was always pestering people with those ideas, as I wanted someone to implement them. So they said "patent them, which will get the ideas out there."
The graphics one was pretty straight forward. Instead of dividing up the picture into rectangles, divide it up into triangles. Set a color for each triangle based on an average of the color pixels in it. Then, smoothly shade the rendering of the triangle based on the colors at each vertex. This will prevent any banding or that ugly blockiness. The number and placement of the vertices depends on the where the complexity in the image is, and of course would be adjustable.
The browser one is to have the browser rendering prioritize where the mouse cursor is. Great for slow connections.
I can imagine this working. Kind of like CW for HAMs, except with a 3-state switch and couple dozen more layers of abstraction between you and the wire :). I wish my Morse code wasn't so rusty though - and it makes me wonder, are there better text encodings that could be used for such purpose?
The method for texting without looking I described was only limited to writing, but it's also something I've done in practice before smartphones, in particular on a Sony Ericsson K800i. This was possible because of good-quality keyboard (and joystick), and good UI decisions. I don't know if they put an actual soft-realtime OS in there (I suspect so), but all the UI delays were always the same - so I naturally memorized sequences like "unlock, menu, texting, wait ~0.5 second for it to load, open thread, type in message, send". It probably takes teenage-level or business-professional-level of use to get that kind of muscle memory, though.
> Instead of dividing up the picture into rectangles, divide it up into triangles. (...) This will prevent any banding or that ugly blockiness.
Is the insight here that a triangle-based subdivision like this will make areas of detail not align on horizontal/vertical lines, unless the underlying image has its details aligned on a band? Or am I misunderstanding this?
> the insight
The vertices will be on pixel addresses. The edges of the triangle will have no discontinuities themselves, and the triangles sharing an edge will have no discontinuities. Hence, no banding or blockiness. A naive renderer would just render the colors of the triangle as a straight linear interpolation. A more advanced one could look at the adjoining triangles, and render it so the first derivative would also be zero across the line. I.e. curve fit it.
The selection of where the vertices go would likely be best selected where the colors are shifting fastest, i.e. an edge in the picture.
The neato thing is one could render a low res image on a high res display and it'll still look good. You wouldn't have these stray pixels scattered around the text like jpg does. The other neato thing is more vertices can be put in the complex areas of the image, rather than wasting bandwidth on the parts of it that are smooth.
Progressive sharpening of the rendering also works, as more vertices can be added at any time.
I have a faint suspicion that your familiarity with finite element models had something to do with your choice of triangles.
I've done finite element models, but they were pretty unsophisticated.
I was alluding the fact that barring boundary effects hexagonal tessellation and equilateral tessellation are essentially the same.
Wow, this threw me back. :) Indeed this was not only possible, but actually easy. I don't think it took a lot of effort or any conscious effort even, actually, the UI was so good, but most importantly there were no unpredictable delays and no unpredictable inconsistencies!
Why is modern software so bad in comparison? Sure it can do more things, but it does them worse. The interface of everything is constantly changing for the unfounded whims of designers who simply think "this looks prettier to me", things are not laid out logically, adverts permeate the interface of most products from phones to TVs...