| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 171.1 | No DECwrite color support in V1 | CADSYS::COOK | ALOE, ALOE | Tue Feb 14 1989 23:59 | 5 |
| I can't answer your question, but the reason why DECwrite only displays
light yellow and white pixels is almost certainly because it does not
support color - and won't for V1. For more, I would sugguest the
QUEEN::EPIC conference.
|
| 171.2 | Color comes out blank... | ASIMOV::KENYON | The Foundation of Science (fiction) | Wed Feb 15 1989 16:46 | 14 |
| re .1
The base note is referring to the phenomena of a drawing which has say 4 lines
of different colors, which is getting transferred into a DDIF file by capture
portion of screen with only 2 lines (provided they are some color which capture
portion of screen decides it will accept). I have seen this with a number of
applications, and haven't been able to figure out just what the problem is (like
.0). The problem occurs in both the DDIF viewer, as well as DECwrite, so I'm
not so sure QUEEN::EPIC is the right place. Since the viewer and write have
the same problem a good starting point might be the capture portion of screen
code...?
-jeff
|
| 171.3 | Not sure, but does this help? | MU::PORTER | Exiled in Cyberia | Wed Feb 15 1989 20:51 | 14 |
| I don't know about capture-in-DDIF format, but capture-in-postscript
format does a colour-to-monochrome conversion on each pixel.
I believe that some weighted sum of the RGB values is computed,
something like
I = aR + bG + cB (don't know what a,b,c are set to)
and if the result I exceeds some limit it's white, otherwise
it's black. This can result in what to your eyes looks like
light-blue-on-white getting captured as white-on-white.
Or is your problem something entirely different?
|
| 171.4 | | DDIF::KROBINSON | Veni,Vidi,Vincemus - DECtop U. | Fri Feb 17 1989 13:10 | 9 |
| .3 has it right. Currently printscreen throws away the color info. This is
just a hack, eventually we will do "the right thing" which, in the ddif case
is to save the color info, and in the postsript case is some sort of dithering
process.
kathy
ps The factors in the calculation are those used by black and white TV, I
believe, and are from Chapter 17.4.3 of Foley and Van Dam.
|
| 171.5 | Not what I would expect... | ASIMOV::KENYON | The Foundation of Science (fiction) | Fri Feb 17 1989 14:56 | 10 |
| If indead the capture portion of screen is doing a "what level are you at",
and if its above make it black, and if below make it white, the algorithm
is not returning what I would expect in the B&W image. With an ECAD layout
package with yellow, green, light brown, red, and purple entities on a black
background, I only get the first 3 showing up in the DDIF image. The red
and purple come out the same as the background in this case (white in the
DDIF image).
-jeff
|
| 171.6 | | VWSENG::KLEINSORGE | Toys 'R' Us | Fri Feb 17 1989 15:24 | 10 |
|
Try doing:
(red * .30) + (green * .59) + (blue * .11)
If it's .5 or above it should be foreground, otherwise it's background.
Red and Purple are most likely to fall below the threshold unless
you increase the lightess of the color with some green.
|