Topic: Does anyone know of a program to control colours? Bulk palette adjusting?

[JonLeung]

Well, I must be doing something wrong, 'cause in Paint Shop Pro I choose "Posterise" and nothing seems to happen...



I could be doing something wrong.  Let me try GIMP instead of this ancient Paint Shop Pro...

[Maxim]

Posterize lets you choose the number of "levels". For example, Master System screens have 4 levels - 0, 85, 170, 255 - so choose 4 and all colours are adjusted to be the nearest colour with those levels.



I use PSP7 (I realise it's traditional to choose an ancient version and never upgrade), but it's been there since I started using it in PSP3.

[JonLeung]

I'm using PSP 3.11 (aheh) but I must be missing something...I can only select up to 7 levels (and not 16) and when I tried it in GIMP 2.0 it didn't work either, and then I tried it again and it made my computer crash.  >_<

[JonLeung]

Since I apparently can't figure out how to posterize properly, would someone be able to make independent colour channel adjusting?

[Maxim]

Shouldn't be too hard. Do you want to specify a full palette, or just a posterisation level? The latter probably won't work as well with non-RGB video chips like the NES's (which works in a kind of HSL colour space), posterisation only works when there are n equally-spaced brightness levels for each colour channel. Is there any standard file format for palettes? Or would a reference image be a better option? Hmm, it's getting tricky...

[JonLeung]

I'd like to specify a full palette.  I was thinking that what would be handy is if I could specify what value should be adjusted to whatever other specific value.  In many cases I would want numbers to round up or down to a multiple of 8.  Or up or down to a multiple of 16.  But sometimes I want to allow certain values like 255 as well, which is why I don't trust leaving it to posterization.



Sure, this could mean I'd have to write out 256 entries in a text file or a convoluted batch file, but I'd only have to make the configurations once for each thing I'd like to try.

[Maxim]

The problem with multiples of 8 or 16 is that they may not be appropriate, especially with different sources producing different colour ranges. For example, stock Gens screenshots range from 0..248 for red and blue channels and 0..252 for green (depending on your graphics card). Rounding each of those to the nearest 8 would disrupt the overall balance between the channels in some cases. On the other hand, specifying 512 colour mappings (for the full 512 possible colours) would be a lot of work. Posterising would also be inappropriate because the colours are starting out as non-full-range - the "correct" adjustment would be to scale the colour channels first, which is becoming really rather complicated.



Can you provide some example images and describe what needs to be done to them?

[JonLeung]

Some of my older maps (I don't know...try my A Link To The Past - Light World maps, or better yet, my April 2005 Link's Awakening Advance map) may have colour errors.  Due to whatever copying and pasting in Paint Shop Pro 3.12, or whatever old thing I used back then, if the palette of the current WIP was 16.7 million colours, for whatever reason RGB values would shift over by like 1-3 when copied and pasted.



I took a peek at the A Link To The Past maps of the same areas on ian-albert.com to see if I could derive some kind of palette file from his work and saw the same problem there.



I'm not going to go all palette-nazi on everyone's maps, just my own.  By adjusting everything to multiples of 8 I feel the maps that aren't correct could be easily fixed.



The problem arises if I want to do something else with the screen captures, like the thumbnails on the front page, and I plan to make more front-page "features" as well.  The thumbnails have particular greys, but due to the copy-and-paste nature of them, many early ones have errors too.



So a palette adjustment thing by individual RGB value that can be applied to multiple images would be a way to fix the unseen things that have been bugging me since the beginning of time (or at least the beginning of VGMaps.com).

[TerraEsperZ]

I ran into similar problems with a combinaison of Gens and Irfanview on my first couple of Sonic CD maps.



See, my desktop is always set to 32 bits color, but Gens always switches it to 16 bits while it runs. So far so good. I ran into a problem when I started assembling screenshots while the emulator was running because whenever I copied a screenshot from Irfanview, it would copy to to clipboard the image being displayed (now in 16 bits) instead of the actual data from the file which was 24 bits. Almost all the colors thus ended up having their individual color channel shifted by a few unit, so everything I would paste on the map canvas while Gens was open would have different color values that wouldn't be apparent to the naked eye but would cause a lot of problems when trying to alter pixels of a specific color value across the whole map.



Paint however remembered the real RGB value of the pixels already there even though the colors displayed might be different because of the 16 bits setting of the desktop. Let's say that I would have a big blue square. The left half of this square is made of (0,0,255) blue while the right half is made of (0,0,252) blue. But because of the 16 bits mode, everything is being displayed as (0,0,252) even though Paint *knows* that internally, both areas have different colors. So, while Gens was still running and causing everything without me suspecting foul play, I would use the Fill tool to try and recolor the whole square only to see that only half of it changed. And when I copied the whole thing in Irfanview to check the RGB values of pixels on both sides, it would give the value of what was displayed which was all (0,0,252) everywhere. All in all, I ended up tracking down the problem, then spent an hour or two recoloring all the problematic pixels on the two maps in question, and now always close Gens once the screenshots have been taken before doing any real assembly in Paint.



---

"With the first link, the chain is forged. The first speech censored, the first thought forbidden, the first freedom denied, chains us all irrevocably." [...] The first time any man's freedom is trodden on, we're all damaged. - Captain Jean-Luc Picard



B*tch, meet reality. Reality, meet b*tch. - Me

[JonLeung]

Don't know if Maxim was still getting around to doing this (making the channel-independent adjusting thing) but it would be nice.  



I'm thinking of checking the colours on my Light World map from The Legend Of Zelda: A Link To The Past, and then if it's not a problem with the printing people, getting a large framed poster of it made up.  I don't like the pictures in our household, but some game-related ones would be nice, and more than just crinkly old Nintendo Power posters...

[Maxim]

Don't hold your breath...

[JonLeung]

Is it a good assumption that all colours on NES/Super NES palettes would be a multiple of 8 (when in decimal)?



That was the purpose of my request for channel-independent colour adjustment...I might have mentioned this before, but before I was all palette-aware, many images that I assembled while in 16.7 million-colour mode on old Paint Shop Pro 3.12 would shift the palette values a little bit when pasted.  I don't know why.  Or if I pasted something overtop of another, you could use the fill tool to see that the underlying image still existed, hiding, because the colours pasted overtop were shifted a certain amount as well.



Be reducing the colours to an indexed 256-colour palette (as many have been when I went on my PNGGauntlet rampage), then following it up with a "only-multiple-of-eight-RGB values-allowed" colour convertor, that would get rid of all these slight shifts that irk my older images and maps...



EDIT: I noticed I did say the same thing four posts earlier...  >_<



I really should learn how to code anything (other than oldschool BASIC ) one of these days...

[Maxim]

If you have your Windows desktop set to 16-bit colour then you can get this kind of thing, although it ought not to be a problem in Paint Shop Pro, more so in Paint.



Mapping consoles' colour definitions to RGB colours is an imprecise art. The NES at least is not even based on RGB, instead it is based on HSL or something similar which does not map easily or necessarily linearly to RGB. Other consoles are RGB based but are often non-linear in their mapping. Emulator authors can take different approaches to implementing them, too, which leads to colour differences between emulators.



Thus, "only multiples of eight" won't help much - it'll clamp colours to those points, but it won't necessarily correct the mistakes you refer to, and it'll mess up all the colours elsewhere.

[JonLeung]

Are there any consoles that are more rigid in their colour definitions?  Do most emulators use approximations?  That must be where I think the "multiples-of-eight" thing comes from.



Back to the 0-85-170-255 Sega Master System example, isn't that a fairly set definition?  Or is that again considered a choice of the emulator coder?

[Maxim]

Let's talk Master System



It defines its colours is RGB with 2 bits per channel, so you have all three channels going from 0 to 3 (64 possible colours). To map that linearly to 0..255 you get the values 0, 85, 170, 255. That's what Meka does.



If you look at that on a typical monitor, the dark colours are a lot darker than they appear on a TV. It also affects the balance of colours some games. But people are kind of used to it so that's becoming the standard.



Some emulator authors did't like over-bright colours. Old versions of Meka used the values 0, 65, 130, 195. eSMS used 0, 57, 123, 189. (eSMS became Emukon but I didn't check its screenshots recently.) I didn't check any other emulators, since Massage and BrSMS are prehistoric relics now, Kega can't save an unfiltered screenshot as far as I can tell, and SMS Plus is hard to find/use (and its page is down at the moment).