Morphic 3.0: The future of the Gui

That makes sense, thanks for the clarification.

Josh


On Aug 29, 2007, at 11:24 PM, Igor Stasenko wrote:

I haven't read the paper, but the video explains the idea quite  
well.  The algorithm operates at the pixel level. When shrinking, it  
removes pixels without adjusting the newly-adjacent pixels, and when  
growing it creates pixels by using the average of the pixels that it  
is to be inserted between.  I think that this technique is great,  
because it provides good results, yet is MUCH simpler to implement  
than the other texture-synthesis techniques that have been published  
at SIGGRAPH in recent years.

Unfortunately this pixel-centricity of the algorithm means that it  
would not be good for high-quality font resizing.  Another main  
reason that this algorithm would not work for fonts is that the  
energy function basically runs the image through an edge detector and  
then finds low-energy paths through the resulting image.  This proves  
to be a good heuristic for photographs, but fonts are pretty much  
"all edge" to an edge detector (I'm thinking of normal-sized document  
fonts, not large fonts used in eg: an advertisement), so the  
heuristic would be unlikely to make good choices about which pixels  
to remove.

The basic problem with high-quality pixel-based font resizing in  
general (not just this technique) is that font design is a very  
difficult skill; experts make a living doing nothing but designing  
fonts.  These people are artists with a fine sense of balance,  
symmetry, etc. who have developed a deep intuition about how slight  
changes in a font will be perceived (typically unconsciously) by the  
viewer.  One pixel can easily make the difference between an  
excellent character and complete rubbish. In order to approach this  
level of performance, the computer program would need to test  
potential font modifications against a model of human visual  
perception.  Even harder, the model should be as sophisticated (read  
"refined", not "complicated") as an expert font designer, not the  
average person.

If available, a much better choice is to use an outline-based font  
(eg: TrueType) and render it at the desired size.

Josh


On Aug 30, 2007, at 8:15 AM, subbukk wrote:

On Wed August 29 2007, Joshua Gargus wrote:
I haven't thought about it too deeply or lately. But, I think it would be
nice, compositionally, if I could massage a sound just like I can a graphic
morph - alter it's 3D position (bigger, father away, left, up, etc.) stretch
it; shrink it both horizontally (time) and vertically (e.g. instrumentation,
orchestration, harmonic), and it's timbre over time.

It'd be nice if sounds could accept drops so that a sound could be dropped on
sounds to create sub-sounds (I guess, you could call them that.) Time is an
issue here, but not hard to accomodate.

And, sounds can be anything from a note, or a sample to a complete music
piece.

FM is already in Squeak - lots of things we could do with an FM sound beyond
the traditional setting up of operators, feedback, LFOs, etc. like
FM/spectral Morphing

I'm not thinking of linear compositional tools such as sequencers or languages
like MusicV, but more multidimensional AND at the object level. I guess more
the lines of CSound or SuperCollider.

The issue with both video and audio is the dimension of time that would
require more thought beyond the concept of stepping.

My point of my original comment was that maybe Morphic 3.0 should step up a
level and include all forms of multimedia from the individual object level.
If we want to do that, I would be involved AND I could find other composers
that would love to help (at least comment on the
ideas/features/architecture.)

brad

On Aug 30, 2007, at 0:20 , Matthew Fulmer wrote:

Well, the Right Thing To Do might be rendering and compositing in  
linear color space and only applying gamma when pushing to the  
screen ... that means you have to have color components of higher  
resolution (16 bit fixed-point? 32 bit floats?) and/or do real super-
sampling ... all of which is expensive. But would be cool to have  
(though most people wouldn't care and rather take performance over  
being "correct").

- Bert -

On 30/08/2007, Juan Vuletich <[hidden email]> wrote:
> I think the problem is well stated. I understand arguments on both
> sides. It's hard to make a decision...
>
Well, i don't think we lose any features with this. There are couple
of ways how to get around the problem, like using special caching
canvas(es).
I think you know why i'm against any operations like getting contents
of screen for using in effects. In case of using OpenGL, for instance,
you actually can obtain the pixel data but as you may know, its very
slow operation and not recommended for use in rendering cycles. This
operation is used only to get screenshots mainly, but not for
rendering effects.
And it sometimes faster and better to redraw given portion of screen ,
by issuing commands second time rather than capture pixel data in
buffer.
Also, please note , that such feature, like getting pixel data is
mainly accessible for display devices. Supporting these ops with
printers or PostScript files or network canvases will require a huge
amount of memory, not saying that it can be incorrect and totally
ineffective.
And different distortion effects is possible to render only if you use
device only for drawing  bitmaps, but suppose that i issuing command
to printer , like draw string of text with specific font. I don't need
to distort it, because printer uses own font glyphs and rasterising
them by hardware, while printing on paper.
Of course you can rasterise glyphs before sending them to printer,
this can be more 'compatible' approach, but very inefficient: you then
forced to rasterise whole document and send it to printer as one big
blob bitmap.
And then we have plotters, on which we can draw using only vectors. If
we support only pixel devices , so we bury possibility to rendering on
vector devices. Or any other devices which simply don't support pixel
rendering.



--
Best regards,
Igor Stasenko AKA sig.