6:58 a.m.
I recently started using a 4k TV as a monitor. The video is natively 4k from the on-board
Intel i7.
I noticed that I often get difficult to read text. This is even worse when I use reverse
video (black bg).
Looking closer I can see that the image changes as I shift the window one pixel sideways.
Seems that
I get a different image when the left margin is odd and when it is even.
I run a test:
============================
#!/bin/sh
show_color() {
x="$1"
fg="-fg $2"
eval xterm $fg $bg -geometry $geo+$((x+0))+$((y+0*dy)) $cmd &
eval xterm $fg $bg -geometry $geo+$((x+1))+$((y+1*dy)) $cmd &
eval xterm $fg $bg -geometry $geo+$((x+2))+$((y+2*dy)) $cmd &
eval xterm $fg $bg -geometry $geo+$((x+3))+$((y+3*dy)) $cmd &
}
bg='-bg black'
cmd="-e 'ls /bin/z* ; read x'"
geo='70x10'
y='200'
dy='160'
off=500
show_color $((off+0)) "rgb:ff/00/00"
show_color $((off+450)) "rgb:00/ff/00"
show_color $((off+900)) "rgb:00/00/ff"
============================
Each column is one color (r, g, b) and each row is shifted one pixel.
Examining the windows with xmag shows clean text without any artifacts.
I am not sure of the policies regarding attachments on this list, I added four small
images
of a closeups of some test screens. Two are green and two are blue. Each pair is shifted
one pixel
relative to its mate. The blue one is worse.
===
Images are now here:
http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08803.jpg
http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08804.jpg
http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08806.jpg
http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08807.jpg
===
Plain white text on black bg and plain black text of white bg is clean. Coloured text is
problematic.
Does anyone have an idea where I can look?
TIA
--
Eyal Lebedinsky (fedora(a)eyal.emu.id.au)
8:03 a.m.
On Mon, 2020-08-03 at 21:58 +1000, Eyal Lebedinsky wrote:
I recently started using a 4k TV as a monitor. The video is natively
4k from the on-board Intel i7.
I noticed that I often get difficult to read text. This is even worse
when I use reverse video (black bg).
Looking closer I can see that the image changes as I shift the window
one pixel sideways. Seems that
I get a different image when the left margin is odd and when it is
even.
You may want to play with aliasing controls for font rendering.
Perhaps your monitor doesn't have the traditional RGB (red green blue)
pixel grouping? It might be in BGR sequence (your photo looks like that from the
defocused blurs on the green text).
--
uname -rsvp
Linux 3.10.0-1127.18.2.el7.x86_64 #1 SMP Sun Jul 26 15:27:06 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
8:55 a.m.
On 2020-08-03 23:03, Tim via users wrote:
On Mon, 2020-08-03 at 21:58 +1000, Eyal Lebedinsky wrote:
> I recently started using a 4k TV as a monitor. The video is natively
> 4k from the on-board Intel i7.
>
> I noticed that I often get difficult to read text. This is even worse
> when I use reverse video (black bg).
>
> Looking closer I can see that the image changes as I shift the window
> one pixel sideways. Seems that
> I get a different image when the left margin is odd and when it is
> even.
You may want to play with aliasing controls for font rendering.
I need to look into this (fonts) but hoped the problem is elsewhere.
Perhaps your monitor doesn't have the traditional RGB (red green
blue)
pixel grouping? It might be in BGR sequence (your photo looks like that from the
defocused blurs on the green text).
I still do not see why placing an windows at an odd x is different from an even position.
Moving the image changes between these two displays with each pixel shift.
BTW this is what the pixels look like:
http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08774-part1.jpg
Looks like BGR left-to-right? Should that matter?
Still, using 'xmag' shows a nice text without any artifacts, so I wonder if this
is an issue
with the actual monitor (TV) - assuming xmag grabs pixels from the screen not knowing how
they were painted (e.g. a font renderer).
--
Eyal Lebedinsky (fedora(a)eyal.emu.id.au)
11:35 a.m.
On Mon, 3 Aug 2020 at 11:53, Eyal Lebedinsky <fedora(a)eyal.emu.id.au> wrote:
I need to look into this (fonts) but hoped the problem is elsewhere.
The aliasing controls are important to make appropriate subixel choices,
not sure why you think fonts could be an issue. There are some issues
related to accurate placement of glyphs versus improved rendering.
> > Perhaps your monitor doesn't have the traditional
RGB (red green blue)
> > pixel grouping? It might be in BGR sequence (your photo looks like that
> from the defocused blurs on the green text).
> I still do not see why placing an windows at an odd x is
different from an
> even position.
> Moving the image changes between these two displays with each pixel shift.
Anti-aliasing uses subpixels, and moving one pixel reverses the colors
between left and right
subpixels: [RGB][RGB][RGB] versus [BGR][BGR][BGR] so you can have
[..B[RG.][...] or
[..R][BG.][...] for a sub-pixel shift to the left. If you want white,
this works. But [..B][.G.][...]
on an RGB display will not look the same as [..R][.G.][...] is you use RGB
settings on a BGR
display.
> BTW this is what the pixels look like:
>
http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08774-part1.jpg
> Looks like BGR left-to-right? Should that matter?
Yes.
> Still, using 'xmag' shows a nice text without any
artifacts, so I wonder
> if this is an issue
> with the actual monitor (TV) - assuming xmag grabs pixels from the screen
> not knowing how
> they were painted (e.g. a font renderer).
Screen capture is usually done from a buffer at the level of pixel colors
and ignores details
of screen painting.
As someone who is near-sighted, I can warn you that eye-glasses tend to
separate colors
(high quality telescope optics have multiple layers with different
materials to get around this).
I can see this by tilting my head up and down or side-to-side.
--
George N. White III
On 2020-08-03 23:03, Tim via users wrote:
> On Mon, 2020-08-03 at 21:58 +1000, Eyal Lebedinsky wrote:
>> I recently started using a 4k TV as a monitor. The video is natively
>> 4k from the on-board Intel i7.
TV's rarely make good monitors. There are very different design tradeoffs.
Monitors are generally designed for close-up viewing and uniformity over a
wide range of viewing angles. TV's are viewed from a greater distance and
narrower range of viewing angles.
Displays good for both purposes are produced in low volumes and can
be very expensive.
> >> I noticed that I often get
difficult to read text. This is even worse
>> when I use reverse video (black bg).
> >> Looking closer I can see that the image changes as I
shift the window
>> one pixel sideways. Seems that
>> I get a different image when the left margin is odd and when it is
>> even.
> You may want to play with aliasing controls for font
rendering.
8:15 p.m.
On 2020-08-04 02:35, George N. White III wrote:
On Mon, 3 Aug 2020 at 11:53, Eyal Lebedinsky
<fedora(a)eyal.emu.id.au <mailto:fedora@eyal.emu.id.au>> wrote:
On 2020-08-03 23:03, Tim via users wrote:
> On Mon, 2020-08-03 at 21:58 +1000, Eyal Lebedinsky wrote:
>> I recently started using a 4k TV as a monitor. The video is natively
>> 4k from the on-board Intel i7.
TV's rarely make good monitors. There are very different design tradeoffs.
Monitors are generally designed for close-up viewing and uniformity over a
wide range of viewing angles. TV's are viewed from a greater distance and
narrower range of viewing angles.
Displays good for both purposes are produced in low volumes and can
be very expensive.
>>
>> I noticed that I often get difficult to read text. This is even worse
>> when I use reverse video (black bg).
>>
>> Looking closer I can see that the image changes as I shift the window
>> one pixel sideways. Seems that
>> I get a different image when the left margin is odd and when it is
>> even.
>
> You may want to play with aliasing controls for font rendering.
I need to look into this (fonts) but hoped the problem is elsewhere.
The aliasing controls are important to make appropriate subixel choices,
not sure why you think fonts could be an issue. There are some issues
related to accurate placement of glyphs versus improved rendering.
> Perhaps your monitor doesn't have the traditional RGB (red green blue)
> pixel grouping? It might be in BGR sequence (your photo looks like that from
the defocused blurs on the green text).
I still do not see why placing an windows at an odd x is different from an even
position.
Moving the image changes between these two displays with each pixel shift.
Anti-aliasing uses subpixels, and moving one pixel reverses the colors between left and
right
subpixels: [RGB][RGB][RGB] versus [BGR][BGR][BGR] so you can have [..B[RG.][...] or
[..R][BG.][...] for a sub-pixel shift to the left. If you want white, this works. But
[..B][.G.][...]
on an RGB display will not look the same as [..R][.G.][...] is you use RGB settings on a
BGR
display.
BTW this is what the pixels look like:
http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08774-part1.jpg
Looks like BGR left-to-right? Should that matter?
Yes.
I followed suggestions I found when searching. Some may be irrelevant to my setup. None
made a difference.
- Applications - Settings - Appearance - Fonts
Sub-pixel order: BGR
- $ gsettings set org.gnome.settings-daemon.plugins.xsettings rgba-order
'bgr'
- $ sudo ln -s /usr/share/fontconfig/conf.avail/10-sub-pixel-bgr.conf /etc/fonts/conf.d/
I logged out/in and killed X to ensure things refreshed. No change.
Funny thing, trying gedit (rather than xterm) for testing, the text is rendered dark blue
in one position
or dark red when the window is shifted one pixel. However, changing the DPI from the
default(96) to 98 makes
the effect almost unnoticeable. It has no effect on xterm or thunderbird.
In fact, dragging this email I can see the text colour flickering between the two effects
as I drag it sideways.
Still, using 'xmag' shows a nice text without any
artifacts, so I wonder if this is an issue
with the actual monitor (TV) - assuming xmag grabs pixels from the screen not knowing
how
they were painted (e.g. a font renderer).
Screen capture is usually done from a buffer at the level of pixel colors and ignores
details
of screen painting.
As someone who is near-sighted, I can warn you that eye-glasses tend to separate colors
(high quality telescope optics have multiple layers with different materials to get
around this).
I can see this by tilting my head up and down or side-to-side.
I may need to find a TV/monitor loaner to have a second reference point.
--
George N. White III
--
--
Eyal Lebedinsky (fedora(a)eyal.emu.id.au)
1:47 a.m.
On Tue, 2020-08-04 at 11:15 +1000, Eyal Lebedinsky wrote:
However, changing the DPI from the default(96) to 98 makes
the effect almost unnoticeable. It has no effect on xterm or
thunderbird.
Some programs (thunderbird, firefox) have their own rendering engines.
Monitors only have one DPI, the *actual* number of dots per inch (which
may not be the same horizontally as vertically). If you use the wrong
data, like how some people like to make their display bigger by lying
to the system, or monitors that fake their ID data, you can notice
rendering errors. Scaling should be done by other means.
--
uname -rsvp
Linux 3.10.0-1127.18.2.el7.x86_64 #1 SMP Sun Jul 26 15:27:06 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
1:43 a.m.
Tim:
> You may want to play with aliasing controls for font rendering.
Eyal Lebedinsky:
I need to look into this (fonts) but hoped the problem is elsewhere.
> Perhaps your monitor doesn't have the traditional RGB (red
green
> blue) pixel grouping? It might be in BGR sequence (your photo
> looks like that from the defocused blurs on the green text).
I still do not see why placing an windows at an odd x is different
from an even position. Moving the image changes between these two
displays with each pixel shift.
With fonts, at least, aliasing is used for sub-pixel rendering. In
other words, they don't just render at the pixel level, they use
portions of the adjacent pixels, too (we might regard one RGB sequence
as one pixel, it can drive each individual R G & B pixel). If the
renderer doesn't know the sequence the pixels are in, it could start to
use non-adjacent pixels. And as you bump things minutely one way or
the other, you may discover rendering flaws.
The font aliasing trick for tiny fonts could also be done for other
graphical drawing (fine lines, etc). I don't know whether Fedora does
that.
BTW this is what the pixels look like:
http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08774-part1.jpg
Looks like BGR left-to-right? Should that matter?
It's kind of hard to tell, but looking at the grouping, with widest gap
between two colours, it looks like green red blue GAP green red blue
Still, using 'xmag' shows a nice text without any artifacts,
so I
wonder if this is an issue with the actual monitor (TV) - assuming
xmag grabs pixels from the screen not knowing how they were painted
(e.g. a font renderer).
As is often said, TV sets don't usually make great monitors
(particularly with fine text). Apart from accuracy issues, they often
have all kinds of processing trying to make real pictures look better
than the TV can display without assistance, or to hide reception
problems.
If you have sharpening turned on, that tries to make a picture look
sharper than it really is, and they rarely do that well. On some sets,
the sharpening control is a boost-only control, where zero is
unmodified. On other sets, it's a boost and cut control, where the
middle position is unmodified, one end is artificially crispened, the
opposite end is artificially softened.
Some TVs actually have a different resolution than what you expect.
They'll render up or down, so you won't get a 1:1 pixel representation.
Putting them into a PC mode can help. Some sets go into an
undocumented PC mode if you rename an input to PC.
Even computer monitors can be awful at rendering tiny text. The goal
of higher and higher resolution monitors is not so much at being able
to render smaller and smaller text, but to better render normal text.
--
uname -rsvp
Linux 3.10.0-1127.18.2.el7.x86_64 #1 SMP Sun Jul 26 15:27:06 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
4:48 a.m.
On 2020-08-04 16:43, Tim via users wrote:
Tim:
>> You may want to play with aliasing controls for font rendering.
Eyal Lebedinsky:
> I need to look into this (fonts) but hoped the problem is elsewhere.
>> Perhaps your monitor doesn't have the traditional RGB (red green
>> blue) pixel grouping? It might be in BGR sequence (your photo
>> looks like that from the defocused blurs on the green text).
> I still do not see why placing an windows at an odd x is different
> from an even position. Moving the image changes between these two
> displays with each pixel shift.
With fonts, at least, aliasing is used for sub-pixel rendering. In
other words, they don't just render at the pixel level, they use
portions of the adjacent pixels, too (we might regard one RGB sequence
as one pixel, it can drive each individual R G & B pixel). If the
renderer doesn't know the sequence the pixels are in, it could start to
use non-adjacent pixels. And as you bump things minutely one way or
the other, you may discover rendering flaws.
The font aliasing trick for tiny fonts could also be done for other
graphical drawing (fine lines, etc). I don't know whether Fedora does
that.
> BTW this is what the pixels look like:
> http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08774-part1.jpg
> Looks like BGR left-to-right? Should that matter?
It's kind of hard to tell, but looking at the grouping, with widest gap
between two colours, it looks like green red blue GAP green red blue
Actually, looking half way down the image, checking for the dark vertical gaps,
the left side looks like GRB and the right side more like BGR. Mmm.
> Still, using 'xmag' shows a nice text without any
artifacts, so I
> wonder if this is an issue with the actual monitor (TV) - assuming
> xmag grabs pixels from the screen not knowing how they were painted
> (e.g. a font renderer).
As is often said, TV sets don't usually make great monitors
(particularly with fine text). Apart from accuracy issues, they often
have all kinds of processing trying to make real pictures look better
than the TV can display without assistance, or to hide reception
problems.
If you have sharpening turned on, that tries to make a picture look
sharper than it really is, and they rarely do that well. On some sets,
the sharpening control is a boost-only control, where zero is
unmodified. On other sets, it's a boost and cut control, where the
middle position is unmodified, one end is artificially crispened, the
opposite end is artificially softened.
Some TVs actually have a different resolution than what you expect.
They'll render up or down, so you won't get a 1:1 pixel representation.
Putting them into a PC mode can help. Some sets go into an
undocumented PC mode if you rename an input to PC.
Even computer monitors can be awful at rendering tiny text. The goal
of higher and higher resolution monitors is not so much at being able
to render smaller and smaller text, but to better render normal text.
I am looking closer at the monitor. I created (gimp) a small test image of red
pixels on black bg. It is simply a run of r-b-r-b-r-b... pixels and the next
row if shifted one pixel.
http://members.iinet.net.au/~eyaleb/attachments/20200801/dots-red.jpg
I now display this image at 100% (1:1) and take a closeup picture. What I see is
nothing like what I expect.
The TV has a number of "picture modes". In standard mode:
http://members.iinet.net.au/~eyaleb/attachments/20200801/standard-mode.jpg
There is a row of all red pixels (should be alternating red and black), with a rather dim
following row.
In PC mode:
http://members.iinet.net.au/~eyaleb/attachments/20200801/pc-mode.jpg
The red row is still missing the black pixels and the dim row is a bit brighter,
rather whitish.
I now suspect the TV more than anything else. I must find another to compare to...
--
Eyal Lebedinsky (fedora(a)eyal.emu.id.au)
9:07 a.m.
On Tue, 2020-08-04 at 19:48 +1000, Eyal Lebedinsky wrote:
>> BTW this is what the pixels look like:
>> http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08774-part1.jpg
>> Looks like BGR left-to-right? Should that matter?
> It's kind of hard to tell, but looking at the grouping, with
widest
> gap between two colours, it looks like green red blue GAP green
> red blue
Actually, looking half way down the image, checking for the dark
vertical gaps, the left side looks like GRB and the right side more
like BGR. Mmm.
Well, it's definitely not RGB, the pixels aren't in that order.
They do fit a BGR sequence.
The gap mayn't be important, that could be manufacturing tolerances, as
well as distorted by chromatic aberrations in the camera lens (blue
will often severely shift focus, and position relative to other
colours).
I am looking closer at the monitor. I created (gimp) a small test
image of red pixels on black bg. It is simply a run of r-b-r-b-r-b...
pixels and the next row if shifted one pixel.
http://members.iinet.net.au/~eyaleb/attachments/20200801/dots-red.jpg
In your browser, zoom in and out with the browser's zoom (on some
browsers that's done with the ctrl and + or - keys). See the various
interference patterns? Some TVs will do those kinds of things with
their normal picture reproduction, because they're processing the
picture, and don't show it "as-is." They try to improve the picture,
by doing things with the adjacent picture data, and that creates
imagery that just didn't exist in the first place.
They can try to sharpen images by drawing an inverse of some of the
image a few pixels over. They can try smoothing out harsh contrast, by
doing the opposite (putting something of an in-between value between
pixels). They may try making colours look more vibrant, but putting
opposing colours around some pixels (it's the old butcher trick of
putting green plastic around meat, to make it look redder). They may
try noise reduction by averaging adjacent areas together. You can get
rendering errors, and sub-standard circuitry that bleeds the signal of
one thing into adjacent things.
Harsh checkerboard test patterns can easily show up design
deficiencies, where the manufacturer only ever expected a telly to show
normal imagery (which tends to have smoother transitions) and designed
it to barely manage to do that.
On my Sony LCD telly, I turned off all the enhancements, because they
just made a mess of the picture. Now, anything shot with a decent
cameraman, and edited by competent person, looks great. I work in
video production, I know what a camera can do, and should look like.
And I remember seeing the cinema classics in 75 mm prints in some
theatres - the cinematography was aesthetically pleasing.
I now display this image at 100% (1:1) and take a closeup picture.
What I see is nothing like what I expect .. [snip]... I now suspect
the TV more than anything else. I must find another to compare to...
I'd be suspicious of your television, too. If it shows nice cinematic
pictures, be happy about that. Most home entertainment gadgets that
display some text on a tv set use large fonts designed to be viewed
from a distance (and small fonts would often look awful, as well as be
hard to read).
--
uname -rsvp
Linux 3.10.0-1127.18.2.el7.x86_64 #1 SMP Sun Jul 26 15:27:06 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
1:42 a.m.
On 2020-08-04 19:48, Eyal Lebedinsky wrote:
On 2020-08-04 16:43, Tim via users wrote:
> Tim:
>>> You may want to play with aliasing controls for font rendering.
>
> Eyal Lebedinsky:
>> I need to look into this (fonts) but hoped the problem is elsewhere.
>
>>> Perhaps your monitor doesn't have the traditional RGB (red green
>>> blue) pixel grouping? It might be in BGR sequence (your photo
>>> looks like that from the defocused blurs on the green text).
>
>> I still do not see why placing an windows at an odd x is different
>> from an even position. Moving the image changes between these two
>> displays with each pixel shift.
>
> With fonts, at least, aliasing is used for sub-pixel rendering. In
> other words, they don't just render at the pixel level, they use
> portions of the adjacent pixels, too (we might regard one RGB sequence
> as one pixel, it can drive each individual R G & B pixel). If the
> renderer doesn't know the sequence the pixels are in, it could start to
> use non-adjacent pixels. And as you bump things minutely one way or
> the other, you may discover rendering flaws.
>
> The font aliasing trick for tiny fonts could also be done for other
> graphical drawing (fine lines, etc). I don't know whether Fedora does
> that.
>
>> BTW this is what the pixels look like:
>>
http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08774-part1.jpg
>> Looks like BGR left-to-right? Should that matter?
>
> It's kind of hard to tell, but looking at the grouping, with widest gap
> between two colours, it looks like green red blue GAP green red blue
Actually, looking half way down the image, checking for the dark vertical gaps,
the left side looks like GRB and the right side more like BGR. Mmm.
>> Still, using 'xmag' shows a nice text without any artifacts, so I
>> wonder if this is an issue with the actual monitor (TV) - assuming
>> xmag grabs pixels from the screen not knowing how they were painted
>> (e.g. a font renderer).
>
> As is often said, TV sets don't usually make great monitors
> (particularly with fine text). Apart from accuracy issues, they often
> have all kinds of processing trying to make real pictures look better
> than the TV can display without assistance, or to hide reception
> problems.
>
> If you have sharpening turned on, that tries to make a picture look
> sharper than it really is, and they rarely do that well. On some sets,
> the sharpening control is a boost-only control, where zero is
> unmodified. On other sets, it's a boost and cut control, where the
> middle position is unmodified, one end is artificially crispened, the
> opposite end is artificially softened.
>
> Some TVs actually have a different resolution than what you expect.
> They'll render up or down, so you won't get a 1:1 pixel representation.
> Putting them into a PC mode can help. Some sets go into an
> undocumented PC mode if you rename an input to PC.
>
> Even computer monitors can be awful at rendering tiny text. The goal
> of higher and higher resolution monitors is not so much at being able
> to render smaller and smaller text, but to better render normal text.
I am looking closer at the monitor. I created (gimp) a small test image of red
pixels on black bg. It is simply a run of r-b-r-b-r-b... pixels and the next
row if shifted one pixel.
http://members.iinet.net.au/~eyaleb/attachments/20200801/dots-red.jpg
I now display this image at 100% (1:1) and take a closeup picture. What I see is
nothing like what I expect.
The TV has a number of "picture modes". In standard mode:
http://members.iinet.net.au/~eyaleb/attachments/20200801/standard-mode.jpg
There is a row of all red pixels (should be alternating red and black), with a rather
dim
following row.
In PC mode:
http://members.iinet.net.au/~eyaleb/attachments/20200801/pc-mode.jpg
The red row is still missing the black pixels and the dim row is a bit brighter,
rather whitish.
I now suspect the TV more than anything else. I must find another to compare to...
Just to add another point. Viewing a b/w checkerboard pattern
http://members.iinet.net.au/~eyaleb/attachments/20200801/dots.jpg
I get a good result
http://members.iinet.net.au/~eyaleb/attachments/20200801/dsc08820.jpg
and it clearly shows a BGR pattern. So the TV can display a 4k pattern.
However there is a problem with colour patterns.
For a test I attached the TV to spare computer with a different os (ubuntu,
I use fedora), different video card (nvidia, I use onboard intel). Same problem.
Interestingly, ubuntu boots into 4096x2160 by default.
--
Eyal Lebedinsky (fedora(a)eyal.emu.id.au)
1358
days inactive
1361
days old
9 comments
3 participants
participants (3)
-
Eyal Lebedinsky -
George N. White III -
Tim