Menu
▾
▴
gnuplot-beta
|
From: Douglas M. <dou...@gm...> - 2011-03-25 17:15:54
|
Dear Developers, There's a little discussion going on at the bug request tracker about making an explicit color column for pm3d. The idea is that rgbimage and "w p lc var" allow you to color each point with an explicit color, not interpolating on a palette. Since pm3d offers options like "corner2colors", which tells pm3d to use a color that is NOT interpolated among nearby points, it seems reasonable that a pm3d option could be made for explicit colors. I was wondering what to make of this related paragraph in the documentation: "Another drawing algorithm, which would draw quadrangles around a given node by taking corners from averaged (x,y)-coordinates of its surrounding 4 nodes while using node’s color, could be implemented in the future. This is already done for drawing images (2D grids) via image and rgbimage styles." I'd love to hear people's thoughts on the possibility of implementing such a feature. If not, can anyone suggest another program that does this? Douglas |
|
From: Ethan A M. <sf...@us...> - 2011-03-25 17:35:31
|
On Friday, March 25, 2011 10:15:28 am Douglas Mason wrote: > Dear Developers, > > There's a little discussion going on at the bug request tracker about making > an explicit color column for pm3d. The idea is that rgbimage and "w p lc > var" allow you to color each point with an explicit color, not interpolating > on a palette. Since pm3d offers options like "corner2colors", which tells > pm3d to use a color that is NOT interpolated among nearby points, it seems > reasonable that a pm3d option could be made for explicit colors. > > I was wondering what to make of this related paragraph in the documentation: > > "Another drawing algorithm, which would draw quadrangles around a given node > by taking corners from averaged (x,y)-coordinates of its surrounding 4 nodes > while using node�s color, could be implemented in the future. This is > already done for drawing images (2D grids) via image and rgbimage styles." > > I'd love to hear people's thoughts on the possibility of implementing such a > feature. If not, can anyone suggest another program that does this? I think that particular hypothetical feature is not what you want. It would guarantee that every color value is the result of interpolation, which generally works badly for RGB colors. Instead, as summarized on the tracker, I think you want an additional option to pm3d that specifies a mapping function Gray_value -> RGB_Color, where Gray_value is not a true continuous value running from [0:1] but instead runs from [0 : 2^24] so that int(Gray_value) is a 24-bit RGB color spec. Although I am not so familiar with the code for pm3d, this sounds possible. Am I failing to see some fundamental difficulty? |
|
From: Ethan A M. <sf...@us...> - 2011-03-25 21:28:08
|
On Friday, March 25, 2011 10:32:05 am Ethan A Merritt wrote: > On Friday, March 25, 2011 10:15:28 am Douglas Mason wrote: > > Dear Developers, > > > > There's a little discussion going on at the bug request tracker about making > > an explicit color column for pm3d. The idea is that rgbimage and "w p lc > > var" allow you to color each point with an explicit color, not interpolating > > on a palette. Since pm3d offers options like "corner2colors", which tells > > pm3d to use a color that is NOT interpolated among nearby points, it seems > > reasonable that a pm3d option could be made for explicit colors. > Although I am not so familiar with the code for pm3d, this sounds possible. > Am I failing to see some fundamental difficulty? Trial patch and sample PNG output now on the tracker. https://sourceforge.net/tracker/?func=detail&atid=352055&aid=3237990&group_id=2055 I can't think of any drawback to allowing "with pm3d lc rgb variable", but go ahead and try to find something that breaks :-) Ethan |
|
From: Petr M. <mi...@ph...> - 2011-03-28 13:31:28
|
> > > There's a little discussion going on at the bug request tracker about making > > > an explicit color column for pm3d. The idea is that rgbimage and "w p lc > > > var" allow you to color each point with an explicit color, not interpolating > > > on a palette. Since pm3d offers options like "corner2colors", which tells > > > pm3d to use a color that is NOT interpolated among nearby points, it seems > > > reasonable that a pm3d option could be made for explicit colors. > > > Although I am not so familiar with the code for pm3d, this sounds possible. > > Am I failing to see some fundamental difficulty? > > Trial patch and sample PNG output now on the tracker. > https://sourceforge.net/tracker/?func=detail&atid=352055&aid=3237990&group_id=2055 > > I can't think of any drawback to allowing "with pm3d lc rgb variable", > but go ahead and try to find something that breaks :-) I've tried it and it works. Interesting feature, I never needed to code explicit colours. --- PM |
|
From: Douglas M. <dou...@gm...> - 2011-03-28 15:03:48
|
I agree, I think it's beautifully done! On Mon, Mar 28, 2011 at 9:31 AM, Petr Mikulik <mi...@ph...>wrote: > > > > There's a little discussion going on at the bug request tracker about > making > > > > an explicit color column for pm3d. The idea is that rgbimage and "w p > lc > > > > var" allow you to color each point with an explicit color, not > interpolating > > > > on a palette. Since pm3d offers options like "corner2colors", which > tells > > > > pm3d to use a color that is NOT interpolated among nearby points, it > seems > > > > reasonable that a pm3d option could be made for explicit colors. > > > > > Although I am not so familiar with the code for pm3d, this sounds > possible. > > > Am I failing to see some fundamental difficulty? > > > > Trial patch and sample PNG output now on the tracker. > > > https://sourceforge.net/tracker/?func=detail&atid=352055&aid=3237990&group_id=2055 > > > > I can't think of any drawback to allowing "with pm3d lc rgb variable", > > but go ahead and try to find something that breaks :-) > > I've tried it and it works. > > Interesting feature, I never needed to code explicit colours. > > --- > PM > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Daniel J S. <dan...@ie...> - 2011-03-28 15:59:54
|
On 03/28/2011 08:31 AM, Petr Mikulik wrote: >> I can't think of any drawback to allowing "with pm3d lc rgb variable", >> but go ahead and try to find something that breaks :-) > > I've tried it and it works. > > Interesting feature, I never needed to code explicit colours. This sounds like something where a person might be able to place an image on a surface, e.g., a photograph wrapped in a spherical shape or a wavy two dimensional sinusoid surface. Could be interesting. Dan |
|
From: Ethan A M. <sf...@us...> - 2011-03-28 17:44:19
|
> >> I can't think of any drawback to allowing "with pm3d lc rgb variable", > >> but go ahead and try to find something that breaks :-) > > > This sounds like something where a person might be able to place an > image on a surface, e.g., a photograph wrapped in a spherical shape or a > wavy two dimensional sinusoid surface. Could be interesting. I think that would have to be another drawing mode entirely. This scheme is an addition to pm3d, where the sampling of the surface is fairly coarse. If isosamples are left at the default, that's only 100 "pixels". What you're describing is more like a texture map. Input a NxM pixmap, distort/project it onto a surface defined by an explicit function or coarse sampling. Ethan |
|
From: Daniel J S. <dan...@ie...> - 2011-03-29 00:42:55
|
On 03/28/2011 12:40 PM, Ethan A Merritt wrote: > What you're describing is more like a texture map. > Input a NxM pixmap, distort/project it onto a surface defined > by an explicit function or coarse sampling. Yes, like a relief map of some sort. Dan |
|
From: Douglas M. <dou...@gm...> - 2011-04-06 20:37:27
|
One item that just occurred to me makes this method extremely versatile. Let's say you have a surface. It should be trivial to calculate the gradient at any point in the surface by simply calculating the difference to each neighboring point. (I wonder if gnuplot could provide this functionality built in or through a clever trick so it can operate with dgrid3d). Based on the technique of normal maps, you can create a function that simply adds or subtracts light (i.e., each RGB channel in unison) based on the angle of the gradient. Or simply provide said normal map which has its own uses. This would permit a perfectly usable bump map in gnuplot, without having to invoke openGL or hellish programming hurdles for the developers. It cannot provide shadows, but I wonder if that's even a good idea anyways. What do you think? Douglas On Mon, Mar 28, 2011 at 8:42 PM, Daniel J Sebald <dan...@ie...>wrote: > On 03/28/2011 12:40 PM, Ethan A Merritt wrote: > > > What you're describing is more like a texture map. > > Input a NxM pixmap, distort/project it onto a surface defined > > by an explicit function or coarse sampling. > > Yes, like a relief map of some sort. > > Dan > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Ethan A M. <sf...@us...> - 2011-04-06 21:36:10
|
Douglas Mason <dou...@gm...> wrote> > > Let's say you have a surface. It should be trivial to calculate the gradient > at any point in the surface by simply calculating the difference to each > neighboring point. Not exactly trivial, but yes it could be done. > Based on the technique of normal maps, you can create a function that simply > adds or subtracts light (i.e., each RGB channel in unison) based on the > angle of the gradient. Or simply provide said normal map which has its own > uses. I take it you are thinking of Gouraud shading, but that's not how it works. The normal at each vertex is used to calculate a different shading at each pixel within the face bounded by those vertices. But gnuplot cannot draw pixel-by-pixel; it draws the entiry face in one go. So differential shading across the face is not possible. > This would permit a perfectly usable bump map in gnuplot A bump map is something else again. But again this results in a per-pixel color distinction. So - nice idea, but not in gnuplot. Ethan |
|
From: Douglas M. <dou...@gm...> - 2011-04-06 22:07:23
|
I'm clearly unlearned in this field! However, I do believe this approach would allow gnuplot to accomplish flat shading (http://en.wikipedia.org/wiki/Phong_shading). Flat shading is more than enough for bump maps when the resolution of the input data is high enough, or interpolated sufficiently. I love the simplicity and specificity of gnuplot, and would never ask that it become some virtual reality rendering tool. However, bump maps are exceedingly useful in certain applications, for instance when conveying terrain or a potential surface (I can share a paper), so having complete control over both the color height function and the lighting (i.e., angle and harshness) would be prized. In these applications, the resolution of the input data is usually greater than what you actually plot. If you have any more input it would be greatly appreciated! On Wed, Apr 6, 2011 at 5:34 PM, Ethan A Merritt <sf...@us... > wrote: > Douglas Mason <dou...@gm...> wrote> > > > > Let's say you have a surface. It should be trivial to calculate the > gradient > > at any point in the surface by simply calculating the difference to each > > neighboring point. > > Not exactly trivial, but yes it could be done. > > > Based on the technique of normal maps, you can create a function that > simply > > adds or subtracts light (i.e., each RGB channel in unison) based on the > > angle of the gradient. Or simply provide said normal map which has its > own > > uses. > > I take it you are thinking of Gouraud shading, but that's not how it works. > The normal at each vertex is used to calculate a different shading at each > pixel within the face bounded by those vertices. But gnuplot cannot draw > pixel-by-pixel; it draws the entiry face in one go. So differential > shading > across the face is not possible. > > > This would permit a perfectly usable bump map in gnuplot > > A bump map is something else again. But again this results in a per-pixel > color distinction. So - nice idea, but not in gnuplot. > > Ethan > |
|
From: Daniel J S. <dan...@ie...> - 2011-04-07 07:08:42
|
Douglas, Could you create an example of what you have in mind using gnuplot with external data? E.g., take some sample data to create a normal shading. Then compute the gradients with some other program and create another plot for that data. All we would need is the two data sets and the commands to create the plots. Dan On 04/06/2011 05:06 PM, Douglas Mason wrote: > I'm clearly unlearned in this field! > > However, I do believe this approach would allow gnuplot to accomplish flat > shading (http://en.wikipedia.org/wiki/Phong_shading). Flat shading is more > than enough for bump maps when the resolution of the input data is high > enough, or interpolated sufficiently. > > I love the simplicity and specificity of gnuplot, and would never ask that > it become some virtual reality rendering tool. However, bump maps are > exceedingly useful in certain applications, for instance when conveying > terrain or a potential surface (I can share a paper), so having complete > control over both the color height function and the lighting (i.e., angle > and harshness) would be prized. In these applications, the resolution of the > input data is usually greater than what you actually plot. > > If you have any more input it would be greatly appreciated! > > On Wed, Apr 6, 2011 at 5:34 PM, Ethan A Merritt<sf...@us... >> wrote: > >> Douglas Mason<dou...@gm...> wrote> >>> >>> Let's say you have a surface. It should be trivial to calculate the >> gradient >>> at any point in the surface by simply calculating the difference to each >>> neighboring point. >> >> Not exactly trivial, but yes it could be done. >> >>> Based on the technique of normal maps, you can create a function that >> simply >>> adds or subtracts light (i.e., each RGB channel in unison) based on the >>> angle of the gradient. Or simply provide said normal map which has its >> own >>> uses. >> >> I take it you are thinking of Gouraud shading, but that's not how it works. >> The normal at each vertex is used to calculate a different shading at each >> pixel within the face bounded by those vertices. But gnuplot cannot draw >> pixel-by-pixel; it draws the entiry face in one go. So differential >> shading >> across the face is not possible. >> >>> This would permit a perfectly usable bump map in gnuplot >> >> A bump map is something else again. But again this results in a per-pixel >> color distinction. So - nice idea, but not in gnuplot. >> >> Ethan >> > -- Dan Sebald email: daniel(DOT)sebald(AT)ieee(DOT)org URL: http://www(DOT)dansebald(DOT)com |
