Subject:
|
Re: Old Dithered Colors
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Wed, 12 Jul 2006 18:48:38 GMT
|
Viewed:
|
1341 times
|
| |
|
|
I still believe that a program must not support the dithering as such.
In principle we could create a new color by mixing the two colors together.
The reason I'm asking is, that without mixing I could make the rendering
engine a bit
faster, and also make things internaly a lot more easy without it.
I think a conversion of the RGB color values to CMY, than adding the colors
and
converting the result back to RGB should to the job.
What do you think?
Or the other way round, what would be the benefit of keeping the dithering?
Michael
"Steve Bliss" <steve.bliss@sbcglobal.net> schrieb im Newsbeitrag
news:J2AzL6.Mns@lugnet.com...
> In lugnet.cad, Michael Lachmann wrote:
> > Hi,
> >
> > I've found a litte spare time to work on MLCad again. The first thing I
> > wanted to do is to implement
> > reading the ldconfig.ldr file.
>
> Awesome!
>
> > With the color meta commands to read I realised that there is a little
> > mismatch with what MLCad internally stores, and what is defined using
> > the meta command.
> > MLCad currently still supports this old dithering methode using two
> > different colors which are drawn nearby to each other in order to
> > create a new virtual color.
> > Sure this methode is no longer required today, but I wonder wether I
> > should
> > still support it, or if I should just drop it.
>
> The underlying assumption that any 'undefined' color code between 256 and
> 511
> should be rendered as a dithered color is still valid. Dithering is a
> 'default'
> behavior, and should be used if no other definition exists for a color.
>
> > At the moment the MLCad standard color table has such colors from color
> > id
> > 256 till 511 most of them without a color name, but some have.
>
> I wonder if the RGB values for the unnamed colors were derived by mixing
> the two
> colors involved in dithering each color id?
>
> > I cannot remember from where I have this color definitions, but so far I
> > found out there is actually no replacement for them, to be more
> > precise they do not even exist, even though the color codes are valid.
> >
> > Can someone help me out of this mess please?
> >
> > To make it short:
> > - Shell MLCad still support dithered colors?
>
> Yes, please!
>
> > - Are there any replacements for this dithered colors 256 to 511?
>
> As you've noticed, ldconfig.ldr has some color id's between 256 and 511.
> These
> color definitions should override the default behavior of dithered
> coloring.
>
> Steve
|
|
Message has 2 Replies:
 | | Re: Old Dithered Colors
|
| (...) I don't see the point in dithering any more either. It slows things down and was meant to simulate colours in the days before 24bit colour was ubiquitous. I would prefer you to just average the two colours (in RGB or CMY). Tim (18 years ago, 12-Jul-06, to lugnet.cad)
| | | Re: Old Dithered Colors
|
| (...) I agree with this, if you mean that the program should calculate the "average" color of the two dithered components. (And this is what LDView has done all along.) (...) I don't understand why you need to perform any color space conversion. If (...) (18 years ago, 12-Jul-06, to lugnet.cad)
|
Message is in Reply To:
| | Re: Old Dithered Colors
|
| (...) Awesome! (...) The underlying assumption that any 'undefined' color code between 256 and 511 should be rendered as a dithered color is still valid. Dithering is a 'default' behavior, and should be used if no other definition exists for a (...) (18 years ago, 12-Jul-06, to lugnet.cad)
|
9 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
