How to draw a one-pixel line??
Loren Pechtel
I'm trying to draw some vector images on a field of tiles. The tiles
are always of integer sizes and can zoom over any reasonable range of
values.
The images themselves are vector images but they don't simply scale
up, as the tile gets bigger more detail is added. (Yeah, I know I'll
have to handle printing a bit differently.)
The problem I'm having is with images composed entirely of vertical
and horizontal lines, black on a gray field.
The horizontal lines are fine, I get exactly what I want. Vertical
lines aren't working too well, though. A lone vertical line is good
enough--two pixels of dark gray instead of one of black but it looks
close enough I didn't even realize it was wrong until I got digging
into the case that's awful:
I have some stripes, some are black/background/background and others
are black/background.
With antialiasing on the ones with the black every three look fuzzy
and the closer ones just look like a blurry blob.
With it turned off I'm getting a very clear image, albeit very wrong:
The three-step one produces dark gray/dark gray/background and the
two-step one simply produces a box of dark gray.
Everything is being drawn on a bitmap that is then put in a
picturebox. The picturebox is in a panel that fills the form other
than a few controls on the right for manipulating the view.
The behavior would make sense if somehow I was drawing between pixels
on the y axis but all the DrawLines are being fed integer coordinates.
Geoffrey Summerhayes
wrote:
My psychic powers must be off today, everything is blurry. Can't see
the code, the size of the bitmap, the size of the picturebox,
properties
of the picturebox, the comments in the code, in fact, even the code!
On a guess, try making the window 1 pixel wider, see if anything
changes.
--
Geoff
Jeff Johnson
news:%23edaYuQ...@TK2MSFTNGP04.phx.gbl...
When you create the Pen you're using to draw your line are you passing a
value of -1 for the width? If not, do so.
vanderghast
the recommended resolution and, in those cases, that is a problem related to
hardware and your choice of resolution. As usual, your problem may be
something else, though.
Vanderghast, Access MVP
"Loren Pechtel" <lorenp...@hotmail.invalid.com> wrote in message
news:%23edaYuQ...@TK2MSFTNGP04.phx.gbl...
Loren Pechtel
<no.pet...@no.nwlink.spam.com> wrote:
>Loren Pechtel wrote:
>> [...]
>> The behavior would make sense if somehow I was drawing between pixels
>> on the y axis but all the DrawLines are being fed integer coordinates.
>
>With no scaling/transformation whatsoever? And you are displaying the
>images also without any scaling or transformation of any sort? How are
>you determining what the exact pixel values are?
>
>Your description sounds as though you're drawing on fractional
>coordinates, in spite of your statement that you're not. But it's also
>possible you're simply not gathering your data correctly and that the
>pixels in the bitmap aren't what you think.
I agree it sounds exactly like fractional coordinates. How do you
draw on fractional coordinates with integer variables, though? There
is no float variable in any routine in the file that actually draws
anything.
Loren Pechtel
I was hoping someone could point me in the right direction without
having to distill down an example. While I've been programming a long
time I'm new to C# so I figure I'm probably making an elementary
mistake.
>
>On a guess, try making the window 1 pixel wider, see if anything
>changes.
No effect.
Loren Pechtel
wrote:
Google kicked that one up already. Width = -1.
Loren Pechtel
wrote:
>You may get that kind of problem with some LCD monitors while being not in
>the recommended resolution and, in those cases, that is a problem related to
>hardware and your choice of resolution. As usual, your problem may be
>something else, though.
Native 1280x1024.
Peter Duniho
> I agree it sounds exactly like fractional coordinates. How do you
By drawing in an environment where coordinates given as integers are
scaling somehow.
I posted a code example that shows that in general, the problem you
describe does not occur. Either your own code does something different,
or you are simply not observing the results correctly (i.e. you think
there's a problem when there's not).
In the latter case, obviously there's nothing to fix. In the former
case, until you post a concise-but-complete code example that reliably
demonstrates the issue, there's no way to tell you how to fix your code.
Pete
Jeff Johnson
news:%23edaYuQ...@TK2MSFTNGP04.phx.gbl...
> I'm having trouble with what seems to be a simple task:
I have to ask: are you absolutely positive you're actually getting
different-colored pixels, or does it just LOOK that way. In other words,
have you saved your bitmap to disk and then loaded it into a graphics
application and increased the zoom so that you can see the individual
pixels?
Peter Duniho
> I have to ask: are you absolutely positive you're actually getting
> different-colored pixels, or does it just LOOK that way. In other words,
> have you saved your bitmap to disk and then loaded it into a graphics
> application and increased the zoom so that you can see the individual
> pixels?
To elaborate on this point: the code example I posted last evening is
specifically designed to illustrate this point. It provides for scaling
the image during presentation, as well as inspecting RGB values for any
specific pixel.
With the example, you can see that scaling the image by (for example)
200%, you get the aliasing behavior described by the OP, but the pixel
values are still exactly as he wants (i.e. 0,0,0 RGB where a black line
is drawn, 128,128,128 on the gray background where it wasn't).
Pete
Loren Pechtel
I managed to reproduce it very easily:
A form containing a panel that contains a picture box. Drawing:
Bitmap Image = new Bitmap(Box.ClientSize.Width
,Box.ClientSize.Height);
Pen Ink = new Pen(Color.Black, -1);
using (Graphics Paper = Graphics.FromImage(Image))
{
Paper.Clear(Color.LightGray);
for (int x = 2; x < Image.Width / 2; x += 2)
Paper.DrawLine(Ink, x, 0, x, Image.Height - 1);
for (int y = 2; y < Image.Height; y += 2)
Paper.DrawLine(Ink, Image.Width / 2, y, Image.Width -
1, y);
}
Box.Image = Image;
Obviously the panel in this case is useless but I simply copied the
layout from the main code--in the main code there are some controls
off to the side and I use the panel to make the picture box take up
the whole form.
This code *SHOULD* draw one half of the screen with vertical lines and
one half with horizontal. I'm getting a gray mass on the left and the
expected behavior on the right.
Loren Pechtel
There should be no scaling in my case--I want to add more detail as
the image gets bigger and thus I'm drawing it at the exact size I want
(or using scroll bars if the minimum acceptable size is bigger than
the window size.)
Loren Pechtel
wrote:
>"Loren Pechtel" <lorenp...@hotmail.invalid.com> wrote in message
When stripes turn into a blob instead it's quite obvious. While I was
working on features other than stripes I didn't realize anything was
wrong, it was close enough.
Family Tree Mike
For what it is worth, I see what you say it *SHOULD* draw when I execute
your routine.
--
Mike
Loren Pechtel
What in the world is the difference then? How do I get it to draw
what you're seeing?
Family Tree Mike
> On Wed, 04 Nov 2009 20:40:56 -0500, Family Tree Mike
> <FamilyT...@ThisOldHouse.com> wrote:
>
>> Loren Pechtel wrote:
>>> On Wed, 04 Nov 2009 12:30:56 -0800, Peter Duniho
>>> <no.pet...@no.nwlink.spam.com> wrote:
>>>
<snip>
>>>
>>> This code *SHOULD* draw one half of the screen with vertical lines and
>>> one half with horizontal. I'm getting a gray mass on the left and the
>>> expected behavior on the right.
>> For what it is worth, I see what you say it *SHOULD* draw when I execute
>> your routine.
>
> What in the world is the difference then? How do I get it to draw
> what you're seeing?
I suspect screen settings. When I set my display settings really
poorly, then I see what you observe. My normal settings are 1680x1050
32 bit color.
--
Mike
Peter Duniho
> What in the world is the difference then? How do I get it to draw
> what you're seeing?
You've yet to establish it's _not_ drawing what Mike is seeing.
Visual inspection isn't good enough. Just because you've drawn a bitmap
a certain way, that's no guarantee it will be presented on the screen
that way.
Pete
Peter Duniho
> There should be no scaling in my case [...]
So you say. But until you post a concise-but-complete code example,
it's not possible to know for sure there's not. If I had a nickel for
every time someone asked a question, 100% certain that their description
of the situation was accurate, only to find it out wasn't...
And even if we establish there's no scaling in the _drawing_ of the
bitmap, there's still some possibility you've got some non-standard
system configuration that is meddling with the display on-screen.
Pete
Loren Pechtel
<FamilyT...@ThisOldHouse.com> wrote:
3x 1280x1024 @ 32bit.
Loren Pechtel
Confirmed--it's drawn right, rendered wrong. It doesn't take blowing
it up to find, either.
Ok, I've been barking up the wrong tree. What could be causing the
errant display?
Peter Duniho
> Confirmed--it's drawn right, rendered wrong. It doesn't take blowing
> it up to find, either.
>
> Ok, I've been barking up the wrong tree. What could be causing the
> errant display?
Lots of things. With a concise-but-complete code example, we could at
least examine how you're using .NET and see whether there's anything
there that would cause the problem. My guess is that it will turn out
to be a system configuration issue, with nothing at all to do with C# or
.NET (in which case, you'll want to try to reproduce similar behavior
with a delivered application -- e.g. WordPad, Paint, etc. -- so that you
can repost your question in a different context, in a different forum).
Obviously, the first thing should be to review everything you're doing
in terms of presenting the bitmap on the screen, to see if you can find
any code or Designer settings you might have enabled that cause some
scaling to occur.
But without a concise-but-complete code example, there's really nothing
more we can offer here in terms of specifics. And even with one, it's
entirely possible the answer will be "works fine on my machine...you
have a configuration problem".
One thing that does come to mind, along the "configuration" lines, is to
verify that your display is using digital input and is a discrete
display technology. Specifically, LCD or plasma, using a DVI or HDMI
input. If the signal is analog at any point, whether in transmission to
the display or in the display itself (e.g. CRT), then that could explain
the results right there. I've never seen any analog output that doesn't
have at least a little blurring.
If you're using an analog signal to an LCD, you _might_ be able to
adjust the synchronization settings (most LCD monitors have an
"auto-adjust", but at the very least there should be manual
image-registration controls) that allows you to get the image as clear
as possible. That still won't provide the perfect image an all-digital
presentation would, but it could be good enough for your purposes.
Of course, if it _is_ a configuration issue -- that is, you've posted a
concise-but-complete code example and several people have confirmed it
works fine on other computers -- then one option is to just forget about
it, at least for the moment. :) After all, if the code is fine, you
can get on with the rest of the program rather than worrying about this
thing. :)
Pete
vanderghast
monitor, and 1920x1200 on a little newer Samsung SyncMaster. BUT if I change
the SyncMaster to 1280 x 1024, then I obtain ugly thick horizontal dark bars
alternating with fine light ones BECAUSE 1280x1024 IS NOT a recommended
resolution for it. Nothing to do with C#, DotNet, the driver, the video
card. In fact, capturing the screen in 1280x1024, saving the file, changing
back the resolution to the recommended one by Samsung for that monitor, and
then displaying the captured bitmap in that new resolution... it shows ok,
the ugly pattern has disappear! Or sliding the image from the Samsung at
1280x1024 onto the Dell also at 1280x1024 (which is the recommended one for
that particular Dell), and the image is drawn as intended!
So my recommendation, try to set the resolution to the recommended one by
the MONITOR maker, and if you have lost the doc, try different resolutions
and keep the one which look best. No code involved.
Vanderghast, Access MVP
"Loren Pechtel" <lorenp...@hotmail.invalid.com> wrote in message
news:OiUW%23PdXK...@TK2MSFTNGP06.phx.gbl...
Jeff Johnson
>> In other words,
>>have you saved your bitmap to disk and then loaded it into a graphics
>>application and increased the zoom so that you can see the individual
>>pixels?
>
> When stripes turn into a blob instead it's quite obvious.
So then that would be a No.
And from the other branch in this thread, it turns out that the bitmap WAS
being created correctly and simply LOOKED wrong on your screen. See how much
trouble you could have saved had you gone this route first?
vanderghast
suggest to take a look at using a textured brush.
Vanderghast, Access MVP
"Jeff Johnson" <i....@enough.spam> wrote in message
news:%23QiYCAa...@TK2MSFTNGP04.phx.gbl...
Loren Pechtel
wrote:
>I can see fine alternated lines on both on both 1280x1024 on a old Dell
>monitor, and 1920x1200 on a little newer Samsung SyncMaster. BUT if I change
>the SyncMaster to 1280 x 1024, then I obtain ugly thick horizontal dark bars
>alternating with fine light ones BECAUSE 1280x1024 IS NOT a recommended
>resolution for it. Nothing to do with C#, DotNet, the driver, the video
>card. In fact, capturing the screen in 1280x1024, saving the file, changing
>back the resolution to the recommended one by Samsung for that monitor, and
>then displaying the captured bitmap in that new resolution... it shows ok,
>the ugly pattern has disappear! Or sliding the image from the Samsung at
>1280x1024 onto the Dell also at 1280x1024 (which is the recommended one for
>that particular Dell), and the image is drawn as intended!
>
>So my recommendation, try to set the resolution to the recommended one by
>the MONITOR maker, and if you have lost the doc, try different resolutions
>and keep the one which look best. No code involved.
My monitors are at their native resolution.
Loren Pechtel
<no.pet...@no.nwlink.spam.com> wrote:
>Loren Pechtel wrote:
>> Confirmed--it's drawn right, rendered wrong. It doesn't take blowing
>> it up to find, either.
>>
>> Ok, I've been barking up the wrong tree. What could be causing the
>> errant display?
>
>Lots of things. With a concise-but-complete code example, we could at
>least examine how you're using .NET and see whether there's anything
>there that would cause the problem. My guess is that it will turn out
>to be a system configuration issue, with nothing at all to do with C# or
>.NET (in which case, you'll want to try to reproduce similar behavior
>with a delivered application -- e.g. WordPad, Paint, etc. -- so that you
>can repost your question in a different context, in a different forum).
I posted a very simple version albeit only describing how to make the
form. It misbehaved.
I saved the bitmap out of it and called it up with the Windows Picture
and Fax viewer, same monitor, everything was fine.
>Obviously, the first thing should be to review everything you're doing
>in terms of presenting the bitmap on the screen, to see if you can find
>any code or Designer settings you might have enabled that cause some
>scaling to occur.
I made a new project. I threw a panel on the main form, dragged it to
the edges. I threw a picture box in it and dragged it to the edges. I
put the previously posted code into it.
>Of course, if it _is_ a configuration issue -- that is, you've posted a
>concise-but-complete code example and several people have confirmed it
>works fine on other computers -- then one option is to just forget about
>it, at least for the moment. :) After all, if the code is fine, you
>can get on with the rest of the program rather than worrying about this
>thing. :)
I am getting on with the rest of it while trying to solve this.
vanderghast
ng message, and are not as 'evident' as the real pictures, but while the
real pictures clearly show the space between the actual point of colors (and
are more uniform in the patterns), they are far too large to be included
here (around 4Meg each).
Vanderghast, Access MVP
"vanderghast" <vanderghast@com> wrote in message
news:uDKu1qkX...@TK2MSFTNGP06.phx.gbl...
> Try to change the resolution then.
>
> Or use a texture brush.
>
>
> Included, for those who would have a hard time to see what it is all
> about,
> photos (from a digital camera) giving an idea of what happen with a
> non-native
> resolution. I need to capture the result with a camera, since a standard
> 'screen capture' captures what is in the video card, NOT what is rendered
> on
> the monitor. The optical zoom of the camera I used was at about 100 mm of
> the monitor, macro capture, no flash (Canon SD 790 IS).
>
>
> Vanderghast, Access MVP
>
>
>
> "Loren Pechtel" <lorenp...@hotmail.invalid.com> wrote in message
> news:eVibFRjX...@TK2MSFTNGP02.phx.gbl...
> (...)
Peter Duniho
>> [...] With a concise-but-complete code example, we could at
>
> I posted a very simple version albeit only describing how to make the
You may find these links useful:
http://www.yoda.arachsys.com/csharp/complete.html
http://www.yoda.arachsys.com/csharp/incomplete.html
http://sscce.org/
In other words: you have yet to post a proper, useful
concise-but-complete code example.
Loren Pechtel
wrote:
>Try to change the resolution then.
It's native and when I save the image and load it with the Windows
picture viewer it works. Thus it's not the monitor but something
that's happening between the bitmap and the screen.
>Or use a texture brush.
What good would that do? (Not that it would work anyway--the stripes
aren't always the same length as each other.)
Loren Pechtel
Since this is graphical code how can I post something that would
actually compile? The form itself is not going to be in the file.
Random
wrote:
> Since this is graphical code how can I post something that would
> actually compile? The form itself is not going to be in the file.
For the purposes of a postable example, of course it could be. Even
if it doesn't bear an resemblence to your application, it's often
helpful to go through this excercise even just to help you debug a
problem. Here's a simple self contained form that compiles and draws
a bunch of vertical lines. If this demostrated a bug, anyone else
here could run it and see the bug for themselves.
using System;
using System.Windows.Forms;
using System.Drawing;
namespace Example
{
public partial class ExampleForm : Form
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new ExampleForm());
}
public ExampleForm()
{
Paint += new PaintEventHandler(ExampleForm_Paint);
}
void ExampleForm_Paint(object sender, PaintEventArgs e)
{
e.Graphics.Clear(Color.White);
for (int x = 0; x < ClientSize.Width; x += 2)
{
e.Graphics.DrawLine(Pens.Black, x, 0, x,
ClientSize.Height);
}
}
}
}
Peter Duniho
>> [...]
>> In other words: you have yet to post a proper, useful
>> concise-but-complete code example.
>
> Since this is graphical code how can I post something that would
> actually compile?
You can do it the exact same way I did.
> The form itself is not going to be in the file.
It will if you put it there.
Pete
Loren Pechtel
<random...@gmail.com> wrote:
>On Nov 5, 4:26�pm, Loren Pechtel <lorenpech...@hotmail.invalid.com>
>wrote:
>> Since this is graphical code how can I post something that would
>> actually compile? �The form itself is not going to be in the file.
>
>For the purposes of a postable example, of course it could be. Even
>if it doesn't bear an resemblence to your application, it's often
>helpful to go through this excercise even just to help you debug a
>problem. Here's a simple self contained form that compiles and draws
>a bunch of vertical lines. If this demostrated a bug, anyone else
>here could run it and see the bug for themselves.
Don't you need the form information also? There's stuff in my test
directory that isn't in this file.
Random
wrote:
> Don't you need the form information also? There's stuff in my test
> directory that isn't in this file.
My crystal ball is murky. I don't know what stuff you're talking
about. When you create a form in a designer, it generally creates 3
files, two source files and one XML file for storying resources.
The csharp compilier takes source files. Unless you've got a specific
binary resource file (i.e., images), there's no reason you can't open
the source files and post them here. After workign through the
excersize of removing any excess code, of course.
vanderghast
betweeness includes the video card and the monitor driver. If you captured
the image, you read what is in the video card (I assume the monitor memory
is write only in most cases), and it seems to prove that the image is ok
there too. So even if you are in native resolution, maybe you use generic
driver for the monitor, rather than the manufacturer one? Furthermore, as
proven by the image I posted (which was captured by an external camera),
your code ***works*** fine. Can you try on another PC?
A texture can repeats itself (wrap mode) to fill variable size area, rather
than being limited to enlarge its original 'pixels' to fit the area, and
will even fill convex area with matching the pattern (example, painting a
T, the texture in the steam is aligned with the texture in the flanges,
automatically... if you use the same brush to paint). See "Pro .Net 2.0
Graphics Programming", by Eric White, at Apress, pp49+
Vanderghast, Access MVP
"Loren Pechtel" <lorenp...@hotmail.invalid.com> wrote in message
news:OOcbofnX...@TK2MSFTNGP02.phx.gbl...
Loren Pechtel
I see nothing in the source file that reflects any properties I set in
the form designer.
Loren Pechtel
wrote:
>As you said, it is between the bitmap, which is ok, and the screen. That
>betweeness includes the video card and the monitor driver. If you captured
>the image, you read what is in the video card (I assume the monitor memory
>is write only in most cases), and it seems to prove that the image is ok
>there too. So even if you are in native resolution, maybe you use generic
>driver for the monitor, rather than the manufacturer one? Furthermore, as
>proven by the image I posted (which was captured by an external camera),
>your code ***works*** fine. Can you try on another PC?
But when I save the bitmap and load it with another program *ON THE
SAME MONITOR* it works.
Thus the system is messing with it (probably scaling it on the x-axis)
somewhere between the bitmap and the screen.
I have a panel on the form, in the panel a picturebox and the image is
put in the picturebox. This is because there is a minimum size the
image must be in order to convey needed information, if I have more
space available than that I try to fill it with optional information
rather than let it go to waste.
>A texture can repeats itself (wrap mode) to fill variable size area, rather
>than being limited to enlarge its original 'pixels' to fit the area, and
>will even fill convex area with matching the pattern (example, painting a
>T, the texture in the steam is aligned with the texture in the flanges,
>automatically... if you use the same brush to paint). See "Pro .Net 2.0
>Graphics Programming", by Eric White, at Apress, pp49+
I'll have a look, although all the texture work is done so I probably
won't touch it.
Peter Duniho
> But when I save the bitmap and load it with another program *ON THE
> SAME MONITOR* it works.
>
> Thus the system is messing with it (probably scaling it on the x-axis)
Sure. And that could be somewhere in your program, or somewhere later
down the line.
Until you post a concise-but-complete code example that reliably
reproduces the problem, there's no way anyone here can tell you for sure
whether it's your program that has a bug, or some configuration issue
external to your own code.
Pete
Random
wrote:
> On Thu, 5 Nov 2009 21:43:11 -0800 (PST), Random
> >binary resource file (i.e., images), there's no reason you can't open
> >the source files and post them here. After workign through the
> >excersize of removing any excess code, of course.
>
> I see nothing in the source file that reflects any properties I set in
> the form designer.
Which source file? There are two for any form created in visual
studio. One (the .Designer.cs) should be pretty much nothing but
properties you set in the form designer.
Loren Pechtel
Yeah--but without it how is it going to work?
Peter Duniho
>> Which source file? There are two for any form created in visual
>> studio. One (the .Designer.cs) should be pretty much nothing but
>> properties you set in the form designer.
>
> Yeah--but without it how is it going to work?
One more time: just look at the code example I posted for an example of
"how it is going to work".
You just need to put all the relevant stuff into a single file. It's as
simple as that.
Pete
Random
wrote:
> >Which source file? There are two for any form created in visual
> >studio. One (the .Designer.cs) should be pretty much nothing but
> >properties you set in the form designer.
>
> Yeah--but without it how is it going to work?
It won't, of course. Since the .designer.cs file is just normal
everyday code, you can combine the two files (and trim out bits
unrelated to your problem description) and post the results. Or, even
better yet, there's nothing stopping you from creating a form from the
ground up like's been shown in a couple of examples now.
vanderghast
bitmaps sizes, a "BitBlt" (tile zoom to fit the space, GDI+ may have another
name for that function) may screw the whole one-to-one representation and
that is where a blur or other inconsistencies could easily show up.
A textured brush would take your available bit map and would not try to
resize it in any way, but rather repeat it (tile it) or crop it as required,
*if* the problem is one linked to the area size. If it is a problem linked
to a poor driver or of monitor resolution, though, it *may* not help,
indeed.
Vanderghast, Access MVP
"Loren Pechtel" <lorenp...@hotmail.invalid.com> wrote in message
news:%23kxo7Ay...@TK2MSFTNGP05.phx.gbl...