Dithering in 16-Color SCI Games

General chat related to ScummVM, adventure gaming, and so on.

Moderator: ScummVM Team

User avatar
MusicallyInspired
Posts: 1022
Joined: Fri Mar 02, 2007 8:03 am
Location: Manitoba, Canada
Contact:

Post by MusicallyInspired » Wed Dec 23, 2009 6:25 am

lazylazyjoe wrote:I had this very conversation last year on this board with a guy, musicallyinspired, who was making a 16 color fan-made sci0 remake of KQ2. I was talking about how the dithering and filtering (on freesci of course) made the games look nicer, but he told me that it altered the way that he designed the game and didn't like it. So, this definitely isn't what the original artists intended. Just another interpretation, like fin said.
That's me!

But yeah, it doesn't work for my particular backgrounds since I did things like use a black line tool in conjunction with a black/brown dithered paint fill to make trees look rugged. It looks right in dithered mode but when you view it in undithered mode they just look like trees with a darker shade of brown and random jagged lines all over the place making it look rather sloppy. So it wouldn't work well for my art.

For Sierra's art I can't really say. I haven't played all the SCI0 Sierra games in undithered mode to be sure. But I imagine something similar to my little art "shortcuts" would crop up and make problems somewhere somehow as well.

madshi
Posts: 7
Joined: Mon Dec 04, 2006 10:41 am

Post by madshi » Wed Dec 23, 2009 8:15 am

m_kiewitz wrote:views/cels "undithering" means really detecting dithered pixel combinations and replacing those with the correct mixed color.
Not sure if it would make a big difference, but you are probably calculating the mixed color by simply averaging the dithered colors, I guess? Have you thought about doing the averaging in linear light? In theory that should produce more correct colors. You know, 8bit RGB is gamma corrected light, not linear light.

http://en.wikipedia.org/wiki/Gamma_correction

On the other hand, the question is how the dithering was done in the first place: If it was done by a computer program based on the colors chosen by the artists, chances are big that the dithering was done in gamma corrected light, too, so undithering should better be done in gamma corrected light, as well. But if the artists draw the dithering themselves manually, maybe undoing it in linear light would be better.

User avatar
m_kiewitz
ScummVM Developer
Posts: 157
Joined: Tue Dec 01, 2009 10:09 am
Location: Daventry

Post by m_kiewitz » Wed Dec 23, 2009 4:46 pm

madshi wrote:
m_kiewitz wrote:views/cels "undithering" means really detecting dithered pixel combinations and replacing those with the correct mixed color.
Not sure if it would make a big difference, but you are probably calculating the mixed color by simply averaging the dithered colors, I guess?
The mixed color is averaging the dithered colors of course. It's the same logic as on background pictures. "undithering" of views/cels is not that easy, because one has to identify dithered pixels. Those could either be just a combination of 2 pixels or in fact a dithered color. That's the problem in Laura Bow 1 currently - those pixels are identified as being dithered, where in fact they aren't and that's why the views/cels get messed up.

User avatar
lazylazyjoe
Posts: 132
Joined: Mon Oct 01, 2007 4:14 pm

Post by lazylazyjoe » Wed Dec 23, 2009 6:17 pm

Would game specific hacks to fix it be too dirty a fix?

madshi
Posts: 7
Joined: Mon Dec 04, 2006 10:41 am

Post by madshi » Wed Dec 23, 2009 8:18 pm

m_kiewitz wrote:The mixed color is averaging the dithered colors of course. It's the same logic as on background pictures. "undithering" of views/cels is not that easy, because one has to identify dithered pixels. Those could either be just a combination of 2 pixels or in fact a dithered color. That's the problem in Laura Bow 1 currently - those pixels are identified as being dithered, where in fact they aren't and that's why the views/cels get messed up.
Yes, that is clear to me.

My point still stands: For your actual undithering code, instead of simple averaging, converting the original dithered colors from gamma corrected light to linear light before mixing, and then back to gamma corrected light after mixing, should produce superior results. Something like this:

Code: Select all

int MixColorComponent(int src1, src2)
{
  src1 = ConvertToLinearLight(src1);
  src2 = ConvertToLinearLight(src2);
  int dst = (src1 + src2 + 1) / 2;
  dst = ConvertToGammaLight(dst);
  return dst;
}

redDst = MixColorComponent(redSrc1, redSrc2);
greenDst = MixColorComponent(greenSrc1, greenSrc2);
blueDst = MixColorComponent(blueSrc1, blueSrc2);
Mixing colors in gamma corrected light is not "correct", although it's often done.

SnowB
Posts: 7
Joined: Thu Nov 11, 2010 5:41 pm

Post by SnowB » Fri Nov 12, 2010 2:27 pm

I was unable to find the sci_undither code in my INI file. Is there another way to undither 16 color SCI games. I'm not too familiar with all the workings of ScummVM yet.

User avatar
envisaged0ne
Posts: 148
Joined: Mon Nov 01, 2010 9:17 am
Location: United States

Post by envisaged0ne » Fri Nov 12, 2010 3:52 pm

Download the latest daily build. It now has an option to enable/disable it in the GUI. Under the Graphics options

User avatar
raina
Posts: 233
Joined: Thu Jan 12, 2006 12:31 pm
Location: Oulu, Finland
Contact:

Post by raina » Fri Nov 12, 2010 6:21 pm

SnowB wrote:I was unable to find the sci_undither code in my INI file.
But nothing's preventing you from putting the setting there. For example, if you want to disable the undithering globally, put

Code: Select all

sci_undither=false
in the [scummvm] section, that's below that line but above any other bracketed lines (=game specific sections).

To enable the undithering for, say King's Quest I SCI, you put

Code: Select all

sci_undither=true
in the [kq1sci] (the default ID for the game) section.

User avatar
LordHoto
ScummVM Developer
Posts: 1030
Joined: Sun Oct 30, 2005 3:58 pm
Location: Germany

Post by LordHoto » Fri Nov 12, 2010 7:07 pm

raina wrote:
SnowB wrote:I was unable to find the sci_undither code in my INI file.
But nothing's preventing you from putting the setting there. For example, if you want to disable the undithering globally, put

Code: Select all

sci_undither=false
in the [scummvm] section, that's below that line but above any other bracketed lines (=game specific sections).

To enable the undithering for, say King's Quest I SCI, you put

Code: Select all

sci_undither=true
in the [kq1sci] (the default ID for the game) section.
In the SVN version of ScummVM the config key was renamed to "disable_dithering", i.e. use "disable_dithering=true" there. But as said before you can use the GUI to change that there too.

SnowB
Posts: 7
Joined: Thu Nov 11, 2010 5:41 pm

Post by SnowB » Fri Nov 12, 2010 7:45 pm

Thanks for the advice, I got the daily build and figured it out. I'll remember the INI advice, though.

gurok
Posts: 2
Joined: Tue Aug 10, 2010 11:19 am

Post by gurok » Sun Dec 12, 2010 11:17 am

Hey m_kiewitz, is there undithering code present for views/cels in the nightlies?

Looking at the first post, I can see some incorrect undithering on the door and cupboards. The little statues beside the door, for instance, should look more like this:
Image

Instead, I don't even get the incorrect undithering seen in the first screenshot. Today's daily snapshot shows all of those details dithered on an undithered background.

Also, I think undithering is a little more complicated than just identifying pixels to be undithered. I would do it in several steps:

- For each pixel:
--- Determine all possible colours the pixel can be (combinations of it and its neighbours)
--- For each colour:
------ Build a region by attempting a "flood fill" with that colour at that pixel's co-ordinates
------- Favour straight vert/horz lines for solid colours
--- Store only the largest region for the pixel in a region list
--- Skip ahead to the next pixel without a region and continue the loop

- Merge the region list into one flattened map:
--- Favour pixels that are more "surrounded" by their region than other pixels -- Think Minesweeper
--- Favour one colour regions over two colour regions
--- If there's still a tie, favour larger regions over smaller ones

- Discard and revert small regions (fewer than 4 pixels)

- Discard and revert two colour regions that only have one colour left in them

- Discard the whole lot if only small (4 pixel) regions were detected

That's roughly the method I used to generate the example above in my quick and somewhat buggy JS implementation.
My flood fill algorithm is dumb and if I rewrote it with a proper flood fill, I'd get much better results, but it's already pretty good:

http://undither.zxq.net/?alcove.png&5
http://undither.zxq.net/?ali-chica.png&13
^ Works in Firefox
Last edited by gurok on Sun Dec 12, 2010 9:14 pm, edited 1 time in total.

User avatar
MusicallyInspired
Posts: 1022
Joined: Fri Mar 02, 2007 8:03 am
Location: Manitoba, Canada
Contact:

Post by MusicallyInspired » Sun Dec 12, 2010 8:07 pm

The way undithering works for the backgrounds is not interpolating any two pixels together. SCI background resources actually use dithered colours as a single colour option in the colour palette separate from each of the colours used. So an SCI background artist has technically 256 colours to work with (16 colours with every possible combination). So ScummVM's undither just interprets these separate colour values as a single colour instead of a dithered colour. Views don't work that way, they only have 16 colours and any dithering is done manually so there's no way for ScummVM to interpret them any differently. Your ideas would come in handy here. But with backgrounds it's automatic if it's in the colour palette.

BobbinT
Posts: 76
Joined: Mon Nov 01, 2010 6:26 pm

Post by BobbinT » Sun Dec 12, 2010 8:27 pm

That looks nice enough. I hope this will be implemented soon. :D

Post Reply