In the spirit of making D2 a first-rate scientific computing language, I have just uploaded the first usable version of my DFL-based dflplot  plotting library to Scrapple.

Right now dflplot is still a work in progress, but it's good enough to be
useful for basic exploratory plotting in a scientific or statistical computing
context, especially in conjunction with other scientific libs like SciD and
dstats.  I'm sure of this because I've been eating my own dogfood with
pre-release versions for the past few days and am amazed at how much more I
like plotting stuff when I can do it w/o having to write stuff out to a text
file and read it back in Python or Octave and instead can plot it directly from D.

dflplot currently supports scatter plots, line plots, histograms, bar plots, quantile-quantile plots and ROC curves.  It also supports subplots.  The following limitations currently exist, which will hopefully be eliminated in short order:

1. Rotated text for Y-Axis labels isn't available in DFL. Therefore, Y-Axis labels are rendered in ugly columnar text.

2. There is currently no "proper" way to save a plot. This is because DFL's Bitmap object doesn't provide a way to obtain the underlying pixels yet, and core.stdc.windows doesn't seem to provide the necessary stuff to do it manually via the Windows API. In the meantime, a workaround (at least for manual, as opposed to programmatic, saving) is to take a screenshot using the print screen key and save this.

3. Clipping isn't supported yet. If you set the axis limits of a plot such that part of the plot would be cut off, an exception is thrown. Clipping will likely be supported in the near future.

4. No options (such as axis limits, title, labels, etc.) are exposed yet via the plot window GUI. This situation will be improved gradually, especially as DFL improves.

5. Only works on Windows. Eventually, I'll abstract away a bunch of the GUI logic and port this to gtkD when it matures, or (hopefully) DFL will be ported to Linux.

The code is located at:  (Eventually this needs a full-fledged project) http://dsource.org/projects/scrapple/browser/trunk/dflplot/dflplot.d

The docs are at:
http://cis.jhu.edu/~dsimcha/dflplot.html

For those who don't want to install dflplot, dfl and dstats (dstats is necessary only for the demo/test function and is otherwise not a dependency) but are curious what dflplot currently looks like, I've attached a screenshot of a subplot window produced by the demo/test function.

On Sat, 10 Jul 2010 04:40:04 +0000, dsimcha wrote:

> 2. There is currently no "proper" way to save a plot. This is because DFL's Bitmap object doesn't provide a way to obtain the underlying pixels yet, and core.stdc.windows doesn't seem to provide the necessary stuff to do it manually via the Windows API.

When using classical windows api, I'm almost entirely sure that only way to have accessible bitmap pixels, while still being able to draw them to window is using dib section.

HANDLE cDC;

HBITMAP hBitmap;

BITMAPINFO bmi;
bmi.bmiHeader.biSize = BITMAPINFOHEADER.sizeof;
bmi.bmiHeader.biWidth = w; // must  be rounded to 4
bmi.bmiHeader.biHeight = -h; // must  be rounded to 4
bmi.bmiHeader.biPlanes = 1;
bmi.bmiHeader.biBitCount = 24;
bmi.bmiHeader.biCompression = BI_RGB;

VOID* ppvBits;

HANDLE cDC = CreateCompatibleDC (hDC);

hBitmap = CreateDIBSection (cDC, &bmi, DIB_RGB_COLORS, &ppvBits, null, 0);

if (hBitmap == NULL || ppvBits == NULL)
    throw new Exception ("Failed to Create Device Independed Bitmap
(DIB)");

HGDIOBJ selectObj = SelectObject (cDC, hBitmap);

if (selectObj == NULL)
    throw new Exception ("Failed to SelectObject the DIB");

ColorBgr* pixRgb = cast (ColorBgr*) ppvBits; // ppvBits are initialized bitmap data

//struct ColorBgr { ubyte blue; ubyte green; ubyte red; }


// to display
BITMAPINFO bi;

bi.bmiHeader.biSize = BITMAPINFO.sizeof;
bi.bmiHeader.biWidth = image.size.width;
bi.bmiHeader.biHeight = 0 - image.size.height;
bi.bmiHeader.biPlanes = 1;
bi.bmiHeader.biBitCount = 24;

SetDIBitsToDevice (hDC,
      0, 0,
      image.size.width, image.size.height,
      0, image.size.height,
      image.size.height, image.size.height,
      &image.pixels[0], &bi, DIB_RGB_COLORS);

Hmm, my first reply seems lost in limbo...


On Sat, Jul 10, 2010 at 06:40, dsimcha <dsimcha@yahoo.com> wrote:

> In the spirit of making D2 a first-rate scientific computing language, I
> have
> just uploaded the first usable version of my DFL-based dflplot  plotting
> library to Scrapple.
>
>
> For those who don't want to install dflplot, dfl and dstats (dstats is
> necessary only for the demo/test function and is otherwise not a
> dependency)
> but are curious what dflplot currently looks like, I've attached a
> screenshot
> of a subplot window produced by the demo/test function.
>

Hey, cool!

I had no trouble installing DFL. Man, I tried that 2-3 times in the past 2 years, to no avail. Now it works, woohoo! Now to get some keyboard shortcut on Code::Blocks to compile with DFL instead of DMD...

Dflplots works quite well for me and is very simple to use. Good work, David!

import std.random;
import dflplot;

void main() {

    auto rnd = uniformDistribution(1000);
    auto rnd2 = uniformDistribution(1000);

    auto scat = ScatterPlot(rnd, rnd2);
    scat.pointSymbol = '.';
    scat.toFigure.showAsMain();
}

As you can see, I use a dot for symbol, it give nice graphics. Maybe with slightly excentered points... I attached a jpeg to my first reply, and maybe that's why it didn't pass.

Out of curiosity, as I don't know DFL, why do you draw everything as text in a scatterplot instead of using small rectangles or lines?

This made me laugh:

/**Hack around ddoc issues.)*/
void dummy() {}

Do you have a missing ')' parenthesis somewhere?

Philippe

== Quote from Michal Minich (michal.minich@gmail.com)'s article
> On Sat, 10 Jul 2010 04:40:04 +0000, dsimcha wrote:
> > 2. There is currently no "proper" way to save a plot. This is because DFL's Bitmap object doesn't provide a way to obtain the underlying pixels yet, and core.stdc.windows doesn't seem to provide the necessary stuff to do it manually via the Windows API.
> When using classical windows api, I'm almost entirely sure that only way
> to have accessible bitmap pixels, while still being able to draw them to
> window is using dib section.
> HANDLE cDC;
> HBITMAP hBitmap;
> BITMAPINFO bmi;
> bmi.bmiHeader.biSize = BITMAPINFOHEADER.sizeof;
> bmi.bmiHeader.biWidth = w; // must  be rounded to 4
> bmi.bmiHeader.biHeight = -h; // must  be rounded to 4
> bmi.bmiHeader.biPlanes = 1;
> bmi.bmiHeader.biBitCount = 24;
> bmi.bmiHeader.biCompression = BI_RGB;
> VOID* ppvBits;
> HANDLE cDC = CreateCompatibleDC (hDC);
> hBitmap = CreateDIBSection (cDC, &bmi, DIB_RGB_COLORS, &ppvBits, null, 0);
> if (hBitmap == NULL || ppvBits == NULL)
>     throw new Exception ("Failed to Create Device Independed Bitmap
> (DIB)");
> HGDIOBJ selectObj = SelectObject (cDC, hBitmap);
> if (selectObj == NULL)
>     throw new Exception ("Failed to SelectObject the DIB");
> ColorBgr* pixRgb = cast (ColorBgr*) ppvBits; // ppvBits are initialized
> bitmap data
> //struct ColorBgr { ubyte blue; ubyte green; ubyte red; }
> // to display
> BITMAPINFO bi;
> bi.bmiHeader.biSize = BITMAPINFO.sizeof;
> bi.bmiHeader.biWidth = image.size.width;
> bi.bmiHeader.biHeight = 0 - image.size.height;
> bi.bmiHeader.biPlanes = 1;
> bi.bmiHeader.biBitCount = 24;
> SetDIBitsToDevice (hDC,
>       0, 0,
>       image.size.width, image.size.height,
>       0, image.size.height,
>       image.size.height, image.size.height,
>       &image.pixels[0], &bi, DIB_RGB_COLORS);

Right.  DFL can give access to the underlying handle for its Bitmap objects (which are basically wrappers around the awful Win32 API).  I have never used the Win32API directly before and tried to paste together some code from MSDN to use GetDIBits.  It didn't work because not all the necessary stuff is declared in core.stdc.windows, so I gave up for now and decided to hope either someone submits a patch to me, or the DFL maintainers wrap GetDIBits in their Bitmap object.

In general, I want to eventually make this lib cross-platform (when gtkD matures, maybe) so I don't want to rely too directly on native OS APIs anyhow.

== Quote from Philippe Sigaud (philippe.sigaud@gmail.com)'s article
> Out of curiosity, as I don't know DFL, why do you draw everything as text in a scatterplot instead of using small rectangles or lines?

This is to give customizability as to what the points look like.

> This made me laugh:
> /**Hack around ddoc issues.)*/
> void dummy() {}
> Do you have a missing ')' parenthesis somewhere?

Probably.  I was getting weird DDoc behavior until I added this, but I can't find the missing ) so I just hacked around it.

> Philippe
> --0022158c15717b3d1b048b047257
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> <div class=3D"gmail_quote">Hmm, my first reply seems lost in limbo...</div>=
> <div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><=
> div class=3D"gmail_quote">On Sat, Jul 10, 2010 at 06:40, dsimcha <span dir=
> =3D"ltr">&lt;<a href=3D"mailto:dsimcha@yahoo.com">dsimcha@yahoo.com</a>&gt;=
> </span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex;">In the spirit of making D2 a first-rate sci=
> entific computing language, I have<br>
> just uploaded the first usable version of my DFL-based dflplot =A0plotting<=
> br>
> library to Scrapple.<br><br><br>
> For those who don&#39;t want to install dflplot, dfl and dstats (dstats is<=
> br>
> necessary only for the demo/test function and is otherwise not a dependency=
> )<br>
> but are curious what dflplot currently looks like, I&#39;ve attached a scre=
> enshot<br>
> of a subplot window produced by the demo/test function.<br>
> </blockquote></div><br><div>Hey, cool!</div><div><br></div><div>I had no tr=
> ouble installing DFL. Man, I tried that 2-3 times in the past 2 years, to n=
> o avail. Now it works, woohoo! Now to get some keyboard shortcut on Code::B=
> locks to compile with DFL instead of DMD...</div>
> <div><br></div><div>Dflplots works quite well for me and is very simple to =
> use. Good work, David!</div><div><br></div><div><div>import std.random;</di=
> v><div>import dflplot;</div><div><br></div><div>void main() {</div><div>
> <br></div><div>=A0=A0 =A0auto rnd =3D uniformDistribution(1000);</div><div>=
> =A0=A0 =A0auto rnd2 =3D uniformDistribution(1000);</div><div><br></div><div=
> >=A0=A0 =A0auto scat =3D ScatterPlot(rnd, rnd2);</div><div>=A0=A0 =A0scat.p=
> ointSymbol =3D &#39;.&#39;;</div>
> <div>=A0=A0 =A0scat.toFigure.showAsMain();</div><div>}</div></div><div><br>=
> </div><div>As you can see, I use a dot for symbol, it give nice graphics. M=
> aybe with slightly excentered points... I attached a jpeg to my first reply=
> , and maybe that&#39;s why it didn&#39;t pass.</div>
> <div><br></div><div>Out of curiosity, as I don&#39;t know DFL, why do you d=
> raw everything as text in a scatterplot instead of using small rectangles o=
> r lines?</div><div><br></div><div>This made me laugh:</div><div><br></div>
> <div><div>/**Hack around ddoc issues.)*/</div><div>void dummy() {}</div></d=
> iv><div><br></div><div>Do you have a missing &#39;)&#39; parenthesis somewh=
> ere?</div><div><br></div><div>Philippe</div><div><br></div><div><br></div>
> --0022158c15717b3d1b048b047257--

On Sat, Jul 10, 2010 at 15:46, dsimcha <dsimcha@yahoo.com> wrote:

> == Quote from Philippe Sigaud (philippe.sigaud@gmail.com)'s article
> > Out of curiosity, as I don't know DFL, why do you draw everything as text
> in
> > a scatterplot instead of using small rectangles or lines?
>
> This is to give customizability as to what the points look like.
>

Maybe you can encapsulate the drawing in a small function that would draw a specific shape and let the user discriminate with an enum?

enum PointShape {circle, square, cross, ...}

Is it possible to cache a small drawing in DFL, to reuse it at will?


>
> > This made me laugh:
> > /**Hack around ddoc issues.)*/
> > void dummy() {}
> > Do you have a missing ')' parenthesis somewhere?
>
> Probably.  I was getting weird DDoc behavior until I added this, but I
> can't find
> the missing ) so I just hacked around it.


Try line 1022 and lines 1988-1990.

For one big file, this irked me so much that I almost wrote a small script that would find docs comments and count parenthesis and brackets in them. But I found the culprit before that :)


As for bitmaps, I have a small module that load 24 bit RGB .bmp as ubyte[3][][] to manipulate them and write an ubyte[3][][] on disk, but it's quite brittle. You indeed need a generic way to save a form to disk as an image.

Philippe

== Quote from Philippe Sigaud (philippe.sigaud@gmail.com)'s article
> --0016e6d975ba9ee1ba048b09a55f
> Content-Type: text/plain; charset=ISO-8859-1
> On Sat, Jul 10, 2010 at 15:46, dsimcha <dsimcha@yahoo.com> wrote:
> > == Quote from Philippe Sigaud (philippe.sigaud@gmail.com)'s article
> > > Out of curiosity, as I don't know DFL, why do you draw everything as text
> > in
> > > a scatterplot instead of using small rectangles or lines?
> >
> > This is to give customizability as to what the points look like.
> >
> Maybe you can encapsulate the drawing in a small function that would draw a
> specific shape and let the user discriminate with an enum?
> enum PointShape {circle, square, cross, ...}
> Is it possible to cache a small drawing in DFL, to reuse it at will?
> >

This is perfectly feasible, technically speaking.  I'm just not sure what it would
buy practically speaking.  I kind of like the way x's and o's look.  Maybe it
would be faster for scatter plots with huge amounts of points, though.  I don't know.

> > > This made me laugh:
> > > /**Hack around ddoc issues.)*/
> > > void dummy() {}
> > > Do you have a missing ')' parenthesis somewhere?
> >
> > Probably.  I was getting weird DDoc behavior until I added this, but I
> > can't find
> > the missing ) so I just hacked around it.
> Try line 1022 and lines 1988-1990.
> For one big file, this irked me so much that I almost wrote a small script
> that would find docs comments and count parenthesis and brackets in them.
> But I found the culprit before that :)

Thanks.  Fixed.

> As for bitmaps, I have a small module that load 24 bit RGB .bmp as ubyte[3][][] to manipulate them and write an ubyte[3][][] on disk, but it's quite brittle. You indeed need a generic way to save a form to disk as an image.

I really want saving to work, but I have no idea what I'm doing Win32 API-wise. I'd say lack of saving support is by far the biggest outstanding issue with DFLPlot.  I'd appreciate any help in this regard.

On Sat, Jul 10, 2010 at 17:42, dsimcha <dsimcha@yahoo.com> wrote:

>
> This is perfectly feasible, technically speaking.  I'm just not sure what
> it would
> buy practically speaking.  I kind of like the way x's and o's look.  Maybe
> it
> would be faster for scatter plots with huge amounts of points, though.  I
> don't know.
>
> I don't know either. It's just it'd give access to some new shapes. But
don't bother, you've much more important things on your plate.



> (parenthesis in doc)
> Thanks.  Fixed.
>

This is a tiring bug in DDoc. I mean, why does it not generate a doc with a
missing parenthesis?
(I guess that's filed as bug 3554)


 > As for bitmaps, I have a small module that load 24 bit RGB .bmp as
> > ubyte[3][][] to manipulate them and write an ubyte[3][][] on disk, but
> it's
> > quite brittle. You indeed need a generic way to save a form to disk as an image.
>
> I really want saving to work, but I have no idea what I'm doing Win32
> API-wise.
> I'd say lack of saving support is by far the biggest outstanding issue with
> DFLPlot.  I'd appreciate any help in this regard.
>

Halas, not from me: I'm at the same stage than you. At max, I'd know how to draw a graph on an empty bitmap, as long as it can be done by lighting individual pixels. And then saving it to disk.  But putting text in it (with D or any other language) is beyond my ken.

I used this technics for a ray-tracer in D and for drawing L-systems, to
learn D :-)
In fact, the only way I found to save the raytracer images to disk was to
manage them as a an array of ubyte[3] and writing this to disk as a 24-but
RGB .bmp file.

I'll let Win32 wizards answer...

Philippe

BTW, since my attachment didn't actually get attached, I've put up the latest screenshot, produced from my demo/testing function, at:

http://cis.jhu.edu/~dsimcha/dflplot.png

"Philippe Sigaud" <philippe.sigaud@gmail.com> wrote in message news:mailman.310.1278794218.24349.digitalmars-d-announce@puremagic.com...
> On Sat, Jul 10, 2010 at 17:42, dsimcha <dsimcha@yahoo.com> wrote:
>
>>
>> This is perfectly feasible, technically speaking.  I'm just not sure what
>> it would
>> buy practically speaking.  I kind of like the way x's and o's look.
>> Maybe
>> it
>> would be faster for scatter plots with huge amounts of points, though.  I
>> don't know.
>>
>> I don't know either. It's just it'd give access to some new shapes. But
> don't bother, you've much more important things on your plate.
>
>
>
>> (parenthesis in doc)
>> Thanks.  Fixed.
>>
>
> This is a tiring bug in DDoc. I mean, why does it not generate a doc with
> a
> missing parenthesis?
> (I guess that's filed as bug 3554)
>
>
> > As for bitmaps, I have a small module that load 24 bit RGB .bmp as
>> > ubyte[3][][] to manipulate them and write an ubyte[3][][] on disk, but
>> it's
>> > quite brittle. You indeed need a generic way to save a form to disk as
>> > an
>> > image.
>>
>> I really want saving to work, but I have no idea what I'm doing Win32
>> API-wise.
>> I'd say lack of saving support is by far the biggest outstanding issue
>> with
>> DFLPlot.  I'd appreciate any help in this regard.
>>
>
> Halas, not from me: I'm at the same stage than you. At max, I'd know how
> to
> draw a graph on an empty bitmap, as long as it can be done by lighting
> individual pixels. And then saving it to disk.  But putting text in it
> (with
> D or any other language) is beyond my ken.
>
> I used this technics for a ray-tracer in D and for drawing L-systems, to
> learn D :-)
> In fact, the only way I found to save the raytracer images to disk was to
> manage them as a an array of ubyte[3] and writing this to disk as a 24-but
> RGB .bmp file.
>
> I'll let Win32 wizards answer...
>

I'm no Win32 expert, but I've recently looked into this sort of thing for a potential side-project, and came up with a few links that might help:

Bitmaps, Device Contexts and BitBlt http://www.winprog.org/tutorial/bitmaps.html

Drawing Text
http://msdn.microsoft.com/en-us/library/dd162490(v=VS.85).aspx

Capturing an Image
http://msdn.microsoft.com/en-us/library/dd183402(v=VS.85).aspx

Windows GDI Documentation
http://msdn.microsoft.com/en-us/library/dd145203(v=VS.85).aspx

One thing to remember if you don't know already is that having direct pixel-by-pixel access involves using an HDIB (Device Independent Bitmap), and all the of built-in drawing functions (like drawing text) involve using a HDC (Device Context) insetad. (Also, HDIBs and HDCs are handles that get passed into free functions, they're not classes or structs.) So there does need to be some converting between HDC and HDIB. I assume "Capturing an Image" covers that, but I didn't look closely.