Re: New version of mesh branch.

On Sun, Feb 5, 2012 at 2:21 PM, Israel Eisenberg <owlgems@yahoo.com> wrote:

>
> Hi Tav,
>
> > I don't have either Illustrator or Corel Draw.
>
> Neither do I, but I have a friend who let me use his ancient Illustrator
> 10
>
>
FYI you can download a trial of the latest Illustrator from our website if
you need to run some experiments:
http://www.adobe.com/cfusion/tdrc/index.cfm?product=illustrator


>
> >  * To edit a patch one seems to need two sets of control points. One set
> > to control the geometric shape of the patch and one set to control the
> > color spread. How does Illustrator handle this?
>
> You define your shape independent of any mesh, fill it with color and to
> turn it
> into a grad mesh you simply click the mesh tool and then click your shape,
> which automatically covered with a basic 2x2 mesh.
> Any corner you click, you can define a color which automatically diffuses
> and
> the control points associated with that point are activated. Editing the
> controls
> distorts the shape and the colors together. So if Illustrator uses two
> sets of
> controls, it's completely transparent to the user.
>
>
I'm not sure I completely understand. When you create a 2x2 mesh in AI, it
will creates a bunch of hidden patches with their own control point.
Is the question how the colors of these points is calculated?


>
> >  * How did you generate the right side image for
> bilinear_combos_compare.html?
>
> Simple export as .jpg. I also exported the same mesh as SVG:
> /basicMesh2x2.svg
>
> >  * Having a derivative of zero along the edge handles the case where the
> > color at the edge is at a maximum or minimum but we also need to
> > smoothly join patches where the color along the edge is in between.
>
> If I understand correctly, by "in between" you mean colors with arbitrary
> RGB
> components, so let me just emphasize what I already wrote in my post:
>
> "No matter what color is at which corner, this configuration ensures
> the derivative of the color change at all boundaries is zero."
>
> And that includes any color whatsoever.
>
> >  (And the problem is more complicated when red, blue, and green all have
> > different profiles.)
>
>
What does a "profile" mean? Does it refer to an ICC profile?


>
> The configuration I suggest (degenerate Hermite + bilinear) doesn't
> really care
> if the red, blue, and green all have different profiles. It will smooth
> colors at any
> boundary, both the boundary where they start and the boundary where they
> end,
> regardless of their components profiles.
> Sorry Tav, but the following paragraph from your page (
> http://tavmjong.free.fr/blog/?p=316):
>
> "Another case where it is impossible to obtain a smooth transition is when
> the different
> primary colors (red, green, blue) have different profiles. In general,
> only the profile of one
> color can be made smooth."
>
> Is no longer valid if colors are interpolated by the Hermite-bilinear
> combination.
>
> Following is a demo of the blue, magenta, and yellow sample from your
> page,
> compared with same colors interpolated by Hermite-linear combo:
>
> http://owl3d.com/tests/Gradient_Mesh/lerpHermite.html
> (fast production, inefficient messy code)
>
> May I suggest to test it with any imaginable colors to realize they are
> *always*
> smooth at *all* boundaries.
>
> >  * I am rethinking our decision to use type 6 rather than type 7 meshes.
>
> PDF standard type 6 and type 7 differ only by the way they map the
> interpolated
> colors to the destination geometry. To interpolate the colors, both use
> bilinear
> interpolation which means both are inherently color-discontinuous at
> boundaries
> and generally, this cannot be corrected by any of their mappings.
>
>
In the past, Illustrator uses types 6 meshes under the hood and type 7 was
generated when a mesh was converted to a different colorspace.
(different profiles have visible differences when you generate intermediate
values. The hope was that type 7 meshes would lessen that effect since they
provide a couple of extra control points.)


>
> To be honest, I haven't read the PDF standard too deep, but if those types
> do not allow incorporating pre-bilinear smoothing interpolants, then I
> think
> the rethinking should be to not use any of them.
>
> >  * I am open to making SVG meshes use something like an interpolant
> > provided that:
> :
> >   3. There is a simple way to export them to PostScript/PDF.
>
> ??? I'm not sure I read this correctly :) Is this an SVG requirement?
>
> People do want to good quality from their meshes.
If you invent a new construct that can't be expressed in PDF or PostScript,
you will need to emulate it with an image.

Not only will this generate larger output, you will also need to calculate
the clip region (which is not trivial).
In addition, the output might look worse, especially on high end devices
that have support for 16bit screening.


> Hello Jasper,
>
> > I'd recommend borrowing the path syntax.
> :
> >  (I'm not sure whether it's worth allowing relative coordinates for
> > colors, but even that would be doable, and might sometimes make sense.)
>
> I think latter remark is more realistic, path syntax is over-specified for
> colors
> and I'm afraid the implementers will reject it.
>
> I think you'll get better traction if you consider keySplines. They carry
> all
> the info you need - start slope, end slope and nicely curved inflection,
> and
> the implementers would love it because the algorithms are already inside
> the UA's.
> Just for the record, the degenerate Hermite I suggest, is precisely
> equivalent
> to keySpline="1/3, 0, 2/3, 1".
>
> I think also the designers will find it easy to edit: matching start slope
> of one
> keySpline to the end slope of its predecessor is not so difficult even for
> those
> who are less comfortable with math.
>
> <linear/radialGradient
> <stop stop-color="" offset="" keySpline=""
>
> Please note this is the old, somewhat lame, definitely orphan, native
> gradient.
> The keySpline define the interpolation from this stop-color to the next,
> and UA's which are yet to support it, will just ignore it.
>
> When the above implemented, with happy tears in my eyes, I'll be able to
> finally visualize, while still alive, the gradient I dreamt about for so
> many cold,
> lonely nights: the ball/sphereGradient:
>
> <radialGradient>
> <stop offset="0" stop-color="aqua"  keySpline="1/3, 0, 2/3, 1/3" />
>
> <stop offset="1" stop-color="navy" />
>
> As for the mesh:
>
> <patch geometry="c..;c..;c..;c.." colors="..;..;..;.."
> keySplines="..;..;..;.." boundaries="..,..,..;..,..,..;..,..,..;..,..,.."
>
> There is space for 4 keySplines, each for a boundary, and the lacuna value
> is
> linear (1/3, 1/3, 2/3, 2/3). Designers should be well educated in the spec
> about
> the different role of color keySplines as compared to the SMIL keySplines.
>
> Here I have a proposal for easier designing: allow the most used
> keySplines
> to be referenced by names. Same like 'red' for the machine is equivalent
> to
> rgb(255,0,0) let, for example, 'linear' be equivalent to '1/3, 1/3, 2/3,
> 2/3'.
>
> Most used keySplines are very few. From the top of my head:
>
> linear (1/3, 1/3, 2/3, 2/3) Trivial.
> hermite (1/3, 0, 2/3, 1) Best symmetric universal smoother there is.
> quadOut (1/3, 2/3, 2/3, 1) ball/sphereGradient start from ball edge
> quadIn (1/3, 0, 2/3, 1/3) climb a ball with quadOut, go down with quadIn,
> slightly counter-intuitive, but this is the way it works. Look for the 0
> slope.
> quadInOut (4/9 ,0 , 5/9, 1) not analytic but good approximation.
> Very useful for Lambertian concave-convex combo.
> Can also be used as a symmetric smoother but is more "bulgier" than
> the Hermite, thus pulls the interpolated colors farther to the center.
>
>
> Back to mesh syntax.
>
> "boundaries" is to inform the UA which boundary of this patch is shared
> with which boundary of another patch. Thus, "boundaries" can contain 1 to
> 4
> semicolon-separated triplets, each triplet is coma-separated.
>
> First part of a triplet is the index of this patch boundary (0,1,2,3) that
> is shared.
> Second part is a reference to another patch in which the shared boundary
> is
> part of its geometry.
> Third part is the index of the shared boundary on the referenced patch.
>
> If the third part is missing, it means the reference of the second part is
> directly to a cubic Bezier regardless if it is boundary of a patch.
>
> So for example: "0, url(#patch2), 2" means first boundary of this patch is
> shared
> with the third boundary of another patch with id="patch2" and "0,
> url(#patch2)"
> means first boundary of this patch is the path with id="patch2", which of
> course
> must be a cubic Bezier and M point replaced by last point of previous
> boundary.
>
> Which brings us to the semicolons in "geometry".
> The UA must be able to distinguish between a degenerate boundary, which
> must be
> explicitly described, and a missing boundary (;;) in which case it will
> find the missing
> geometry in a boundary referenced in "boundaries".
> Without semicolons, the UA cannot tell which index boundary is missing.
>
> Needless to say, this system allows describing any boundary only once.
>
> Off the scope of gradient mesh, the geometry/boundaries syntax can be
> adopted to maps composed of many states/districts/neighborhoods.
> In maps of course, the number of boundaries will not be limited to 4
> as also a single boundary will not be limited to cubic Bezier.
>
>
> >  ...For example, if both interpolation types are cubic, then
> > essentially you could just allow a user to select colors per control
> > point (instead of only at the corners).
>
> If those cubics are Beziers, which generally do not interpolate their
> control points,
> how will you achieve precise control over the result color at control
> points?
>
> But if precise control over non-corner colors is not a requirement, then
> this is
> certainly a fascinating feature: 16 different colors on a single patch(!)
> what a trip...
>
> Regards,
> Israel
>
>