Palette talk

Make games! Discuss those games here.

Moderators: Bob the Hamster, marionline, SDHawk

User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

Oion9 wrote:
Pepsi Ranger wrote:CHGPAL doesn't consider degrees of color needed for lighting or shading
Not sure what you mean by that, Pepsi. All I can say is that it simply examines the old palette, and finds a 'best match' in the new palette for each color in the old palette. The rest of the code simply applies that, with a small level of intelligence, to the graphics in the RPG file.
It's been a while since I've made that comment, but I think I was referring to the fact that the original palette (the one that we were using back in 2000) uses color ramps for 16 shades of each respective basic color (red, yellow, blue, etc.) and 5 or 6 shades for more secondary colors (cyan, hot pink, etc.). Since most newly constructed palettes use an average of 4 shades per color, I think I was worried about light or shadow loss if the conversion takes two colors from a nearby position on the old ramp and merges them into the same color on the new ramp, should the new ramp have more drastic contrasts between each shade. I don't think it's as much of an issue with the palette that the OHR defaults to nowadays, since I think the average ramp is something like 8 shades of the same color on that one (if I recall correctly), but because most of my games are still on the original OHR palette, I think they might be harder to convert cleanly. For small games, that's not a big deal. For a game like Powerstick Man, it's a nightmare to think about just turning beach sand from yellow to tan when every other color on the old palette is used somewhere.
Place Obligatory Signature Here
0ion9
Red Slime
Posts: 40
Joined: Sun Aug 02, 2009 7:45 am

Post by 0ion9 »

I see why that would be a problem. Thanks for the explanation.

I think that could be addressed by the multiple iteration -> pick remapping with minimal global error strategy. Of course, this wouldn't guarantee no duplication at all. Probably it would be necessary to combine it with the no-duplication-forcing strategy (which is probably best used for sprites, since any bad color fits can be adjusted quickly by the user)

This is a bit academic, since I'm not currently planning to rework CHGPAL; plenty of other stuff to do.

The average ramp in the current palette is 15-long, BTW. At least that's what it looks like superficially ;)
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Since that sphere packing palette is so regular, wouldn't it be possible to sort it into ramps according to a pattern rather than a highly irregular sorting by hand? Or maybe that is what it already is.
0ion9 wrote:Also for palette swapping purposes. I don't think pal swaps are going to go away.
Yes. Although I still don't know quite how we support 24 bit colour, not just for alpha blending but in the sprites themselves. Multiple 256-colour palettes and completely unpaletted sprites. How can you have all of flexibility, simplicity, and back-compatibility?

Good luck, it's a notoriously difficult problem to pick good dither colors programmatically.
It's an interesting problem, but I don't want to become too distraced by it. Probably I should just commit what I have for importing/quantising 24 bit files, maybe add a LAB colourspace version, and not try to do anything fancy to handle problems like colour bleeding across edges. Users can compare and select the best.

But colour distance is used in several places, e.g. UI colour mapping, and a blending tool in the graphics editors would be nice.

Thanks also for reminding me of that libcaca study. I've seen it before but I think it's been extended since... though I've never read through the whole thing. It's very interesting to hear that void-and-cluster could be useful for animations. In general I found that dithering algorithms seem to do quite badly for remapping pixel art; they're really designed for fairly high resolution photographic images.

And thanks for all that other information. Does it make any sense to have linear Lab distance as an option?
0ion9
Red Slime
Posts: 40
Joined: Sun Aug 02, 2009 7:45 am

Post by 0ion9 »

Yeah, the sphere packing palette was already sorted, in a way similar to standard colorcubes. Which is actually okay for small palettes, but IMO quite cumbersome when palette size gets bigger than say 64.
Irregularity is not important IMO (as long as ramps aren't wrapping across rows -- which I'm expecting will be handled fairly comprehensively by the time this palette is properly sorted, just swap ramps around to get a neat packing)

IMO how suitable a dithering setup will be depends on how closely it will be scrutinized. If color resolution is more important than pixel precision (eg. a large filled area/gradient -- animated BG or tile) then void+cluster would be a good choice, otherwise IMO there are only two options: No dithering, and dithering with a 2x2 bayer matrix, eg.

Code: Select all

1 4 
3 2
We've currently got this thread running over at pixelation. There has been some back and forth about dither but currently Howard's using a 2x2 bayer matrix and IMO it's working pretty well.
Although I still don't know quite how we support 24 bit colour, not just for alpha blending but in the sprites themselves. Multiple 256-colour palettes and completely unpaletted sprites. How can you have all of flexibility, simplicity, and back-compatibility?
Well, you can have paletted 24bit sprites. I did it for Bub'N'Bros, where my revamped dragon graphics were using 384 colors / sprite. Palettization is done using a hashtable incolor:outcolor; you read the input RGB; if it's in the hashtable you write the result of the lookup as the output RGB, otherwise you write the input RGB as the output RGB. Do whatever with the alpha channel (copy it straight across or allow RGBA values in the palette and multiply input alpha by palette alpha).
This is definitely slower than a standard palette lookup, but I'm not sure how much slower.
It does depend on every sprite having a default palette.

It's certainly a complex problem. Perhaps the above might be a useful ingredient though.

(A faster implementation would reserve 1 bit of alpha (or blue if no alpha) for internal use; if that bit was set then the rest of the color would be treated as an index into a palette.)
Does it make any sense to have linear Lab distance as an option?
For measuring color difference? Not really IMO; the CIE76 formula sqrt((L2-L1)^2 * (a2-a1)^2 * (b2-b1)^2) is as simple as it can reasonably get (and as wikipedia and colorwiki note, still has noticable problems)

If you decide not to get into Lab at all, euclidean distance in linear RGB is still an improvement on euclidean distance in sRGB (and the conversion can be done quickly using a lookup table). Since your thread doesn't show code, I'm not sure whether you are already aware of that.
Last edited by 0ion9 on Tue Oct 13, 2015 1:27 am, edited 3 times in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

We've currently got this thread running over at pixelation. There has been some back and forth about dither but currently Howard's using a 2x2 bayer matrix and IMO it's working pretty well.
Hmm, that is pretty convincing for adding ordered dithering as an option.
Well, you can have paletted 24bit sprites. I did it for Bub'N'Bros, where my revamped dragon graphics were using 384 colors / sprite. Palettization is done using a hashtable incolor:outcolor; you read the input RGB; if it's in the hashtable you write the result of the lookup as the output RGB, otherwise you write the input RGB as the output RGB. Do whatever with the alpha channel (copy it straight across or allow RGBA values in the palette and multiply input alpha by palette alpha).
This is definitely slower than a standard palette lookup, but I'm not sure how much slower.
It does depend on every sprite having a default palette.
That's an interesting idea. Although I think allowing both paletted and unpaletted pixels in the same sprite, while cool and definitely having a number of uses, seems like the sort of complexity that's not worth making a goal unless it's easy to add. Also, the implementation I would use: set aside RGB triplets of a certain form, eg (X, 233, 233) with X=0 to 255, to encode the paletted colours (ie use a 16 bit flag rather than a 1 bit one as you suggested). Or allow more than 8 bits for the palette index. With such an implementation it seems it would be easy to support in Game, 90% of the work in supporting new graphics formats is supporting them in the graphics editors, including UI, importing, exporting, and separate 8/24/32 bit implementations of everything, etc. If we didn't have graphics editors we would have removed the 16 colour limit long ago.

Another question is whether there's any point having support for palettes with more than 256 colours if you can use multiple master palettes and also 24 bit graphics. I suppose having a single large master palette is more manageable than several smaller ones.

For measuring color difference? Not really IMO; the CIE76 formula sqrt((L2-L1)^2 * (a2-a1)^2 * (b2-b1f)^2) is as simple as it can reasonably get (and as wikipedia and colorwiki note, still has noticable problems)

If you decide not to get into Lab at all, euclidean distance in linear RGB is still an improvement on euclidean distance in sRGB (and the conversion can be done quickly using a lookup table). Since your thread doesn't show code, I'm not sure whether you are already aware of that.
Oh, I forgot that CIE76 is just regular Euclidean distance. I just want to provide a few different options, preferably significantly different even if they give poor results much of the time, so that people can try all of them and use the best one. Too many options may also be bad (linear RGB, CIE 94) x (nearest match, ordered dithering, F-S dithering) is already 6 options.
I was quite clueless about the difference between RGB and sRGB when I began.
Last edited by TMC on Tue Oct 13, 2015 9:58 am, edited 1 time in total.
0ion9
Red Slime
Posts: 40
Joined: Sun Aug 02, 2009 7:45 am

Post by 0ion9 »

That idea was really just brought up because you mentioned '24bit.. and need to support palettes as well'. If you're gonna make all graphics the same depth, then a hybrid format is needed, a plain RGB(a) cannot guarantee no-data-loss (because differing source indices may be mapped to the same color).

Your scheme is more efficient, of course. Personally I would be aiming for a scheme where there's only one condition, which seems to be the case for your X, 233, 233 scheme but probably wouldn't be the case for a similar scheme supporting >256 palette entries.

Whether >256 or <=256 paletted colors are allowed, I think we have to work out some kind of sensible mapping for old 16color palettes. If each sprite (preferably each sprite set) has it's own palette, this won't be a problem. If it has to be mapped to a global one, it could easily be a problem, as sprite palette swapping commands could have side effects on later sprite rendering.

So to me, the global palette sounds attractive but I don't see how sprite palette backcompat can be reliably managed with such a thing.
(That said, I don't see how master palette plotscripting backcompat can be reliably managed WITHOUT such a thing either, since proper individual sprite palettes wouldn't contain references to a master palette)

I mean, it's beginning to sound to me like

Code: Select all

24bit sprite,
  with special case for paletted indices
     that refer to a per sprite palette
        containing indices into
           a master palette with actual RGB values
may actually be needed. I hope not, because aside from being horrifying on a complexity basis, a conditional check and three memory lookups per paletted pixel ain't efficient.

(I get the feeling that there might yet be an elegant solution here, but I certainly haven't found one so far.)

Your # of options doesn't seem too much to me, because AFAICS anyone who wants a consistent appearance will end up picking one of the dithering type options and sticking with it, leaving only a choice of color matching method.
Last edited by 0ion9 on Wed Oct 14, 2015 2:42 am, edited 3 times in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Terminology: Let's call the 16-colour palettes which index into a master palette containing RGB colours `local palettes'.

A singular universal graphical format might simplify the graphics editors a bit, but it's not a requirement. Each spriteset could be stored in a different format, as well as differing in other ways such as size of frames, but that doesn't matter here.

By considering a RGB triple as a 24 bit integer any number of bits can be used as a flag for palette indices. The problem is that this scheme, and also palettes larger than 256, do no import/export to a format that's nice to work with or common, and I think the editor for any mixed paletted/unpaletted graphics would be super confusing anyway.

One thing that has been asked many times is "how can I fade out the whole screen except for the textbox/the hero/etc?" I think that's where I actually got the idea for multiple master palettes, since it makes such palette manipulations much simpler than if all local palettes index into a single master. Now that I think about it, the alternative once we have alpha blending is to fade in a black rectangle inbetween the foreground and background, though there are a number of other uses, such as being able to have different master palettes for the UI and for the everything else, and modify the later master palette for time of day. Another use is ability to import graphics which use any master palette without remapping. Still, I would be in favour of not having more than one master palette if we can do without them by using workarounds for these things.
Whether >256 or <=256 paletted colors are allowed, I think we have to work out some kind of sensible mapping for old 16color palettes. If each sprite (preferably each sprite set) has it's own palette, this won't be a problem. If it has to be mapped to a global one, it could easily be a problem, as sprite palette swapping commands could have side effects on later sprite rendering.

So to me, the global palette sounds attractive but I don't see how sprite palette backcompat can be reliably managed with such a thing.
(That said, I don't see how master palette plotscripting backcompat can be reliably managed WITHOUT such a thing either, since proper individual sprite palettes wouldn't contain references to a master palette)
I didn't really understand much of this. Does "global palette" mean a single master? Also, maybe you're not aware that every spriteset in the engine does now have a default local palette, so it's never necessary to specify it elsewhere unless you're using palette swapping.

The obvious way to handle existing local palettes is to extend them to 256 colours, but remaining local. Supporting multiple master palettes would be done by associating every local palette with a master palette, defaulting to the default. When importing a spriteset you would have the option of either remapping it to an existing local palette (already exists), importing it with a new local palette into the default master palette (already exists), creating both new local and master palettes, or importing it as a 24/32 spriteset. If a spriteset is unpaletted, the associated palette option in Custom would show "N/A", and there's no reason to add ability to select master palettes anywhere except in the palette editor. Using script commands to set the palette of an unpaletted sprite would be an error or ignored. Changing the local palette of a sprite of course implicitly switches to the correct master palette. Script commands for modifying the master palette, including fadescreenin/out would get new optional arguments to select the master palette. Script commands for editing local palettes are overdue.

I don't expect script command backcompat will be any problem regardless of the scheme we use.
...may actually be needed. I hope not, because aside from being horrifying on a complexity basis, a conditional check and three memory lookups per paletted pixel ain't efficient.
But this double palette lookup is actually what we have now, except without any unpaletted 24 bit pixels (which adds one extra branch), and the second lookup is deferred until the whole rendered screen is sent to the display (which is probably a bit faster). It's true that the double lookup is less efficient than a single palette lookup but I wouldn't say that matters. But I would like to switch to hardware accelerated graphics, which would be nice for alpha blending/tinting/rotation/scaling, especially at higher resolutions. However SDL2, OpenGL, and other modern graphics interfaces don't support paletted textures at all anyway except through shaders and no-longer-supported extensions. The correct solution is GLSL shaders (I think OpenGL 2.0 would be sufficient), the more portable (non OpenGL specific) solution is to convert all sprites to RGB888 before handing them to the graphics library, the easiest solution is to use our existing software renderer, written by Jay, at least for now, although it's currently far too slow for practical use but could probably be sped up by removing some unnecessary features, or just getting optimised routines from elsewhere. (Sorry, pretty offtopic)

I actually proposed allowing spritesets to contain indexes into the master palette rather than a local palette, but having two different types of paletted sprites is extra complexity. It would be the same as a local palette which does an identity mapping to the master palette. Which kind of complexity is worse? The kind that creates a bigger mess if you have a mixture of old and new palettes in the same game, but lets you have a simpler UI you if don't use local palettes, or the kind with fewer options to worry about in sprites, when importing/exporting etc, but which forces to you always use the complex local+master palette UI in the sprite editor?


OK, 6 options is fine. Of course, all these dithering and colour distance algorithms have parameters that can be tweaked e.g. for importance of saturated colours, which might be useful for remapping to an inappropriate palette, but that might be overwhelming. On the other hand we already have this quite confusing UI for forbidding certain colours in the palette. I would like to get rid of it, but I fear it is useful.
Last edited by TMC on Wed Oct 14, 2015 12:19 pm, edited 1 time in total.
0ion9
Red Slime
Posts: 40
Joined: Sun Aug 02, 2009 7:45 am

Post by 0ion9 »

TMC wrote: A singular universal graphical format might simplify the graphics editors a bit, but it's not a requirement. Each spriteset could be stored in a different format, as well as differing in other ways such as size of frames, but that doesn't matter here.

By considering a RGB triple as a 24 bit integer any number of bits can be used as a flag for palette indices. The problem is that this scheme, and also palettes larger than 256, do no import/export to a format that's nice to work with or common, and I think the editor for any mixed paletted/unpaletted graphics would be super confusing anyway.
Yeah, you're probably right there.
Also, maybe you're not aware that every spriteset in the engine does now have a default local palette, so it's never necessary to specify it elsewhere unless you're using palette swapping.
No, that was part of the problem AFAICS. I mean, having a default palette does make the common case simple, but since that palette -can- be swapped, it doesn't ultimately simplify the solution much.
The obvious way to handle existing local palettes is to extend them to 256 colours, but remaining local.
I feel forced to agree, though it seems icky.
Supporting multiple master palettes would be done by associating every local palette with a master palette, defaulting to the default. When importing a spriteset you would have the option of either remapping it to an existing local palette (already exists), importing it with a new local palette into the default master palette (already exists), creating both new local and master palettes, or importing it as a 24/32 spriteset.
That's a bit much. Maybe a general option is needed? Certainly, if someone wanted to import in 24/32bit, and later convert to paletted as needed, then they would spend a lot of time selecting the exact same menu item.

Could it be broken down as follows:
* import either as 24/32bit or with new local palette
Possibly with a per-sprite-type default for which to do.
* separate operation to convert 24/32bit <-> local+master
* separate operation to remap local palette to existing master or existing local.
* (maybe) GC operation for master palettes -- delete unused ones.

I feel that separates the common and uncommon operations better.
If a spriteset is unpaletted, the associated palette option in Custom would show "N/A", and there's no reason to add ability to select master palettes anywhere except in the palette editor. Using script commands to set the palette of an unpaletted sprite would be an error or ignored. Changing the local palette of a sprite of course implicitly switches to the correct master palette. Script commands for modifying the master palette, including fadescreenin/out would get new optional arguments to select the master palette. Script commands for editing local palettes are overdue.
Yeah. Especially agree that scripted local palette editing is overdue.
It's true that the double lookup is less efficient than a single palette lookup but I wouldn't say that matters. But I would like to switch to hardware accelerated graphics, which would be nice for alpha blending/tinting/rotation/scaling, especially at higher resolutions.
It doesn't matter with the current local palette size (16 + 256 * 3 = 784 bytes of cache / sprite). Not so sure this will hold true when local palettes are 256 entries (1024 bytes of cache / sprite).
Anyway, I agree this will basically be moot if rendering becomes shader-based.
I actually proposed allowing spritesets to contain indexes into the master palette rather than a local palette, but having two different types of paletted sprites is extra complexity. It would be the same as a local palette which does an identity mapping to the master palette. Which kind of complexity is worse? The kind that creates a bigger mess if you have a mixture of old and new palettes in the same game, but lets you have a simpler UI you if don't use local palettes, or the kind with fewer options to worry about in sprites, when importing/exporting etc, but which forces to you always use the complex local+master palette UI in the sprite editor?
Not sure. Some basic statistical analysis of existing RPG files might help
(eg. ratio between # of graphic sets that are used with 2+ different 16col palettes, and those that are used with exactly one); I suspect it would come out in favor of your 'direct mapping' idea.
OK, 6 options is fine. Of course, all these dithering and colour distance algorithms have parameters that can be tweaked e.g. for importance of saturated colours, which might be useful for remapping to an inappropriate palette, but that might be overwhelming.
I think that is the common consensus, given how few comparable UIs offer these options.
Personally, I favor a separate preprocessing step to achieve things like saturation weighting and regularization.
On the other hand we already have this quite confusing UI for forbidding certain colours in the palette. I would like to get rid of it, but I fear it is useful.
Maybe I just use GrafX2 too much, but I find that UI simple.
Last edited by 0ion9 on Thu Oct 15, 2015 1:54 am, edited 3 times in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Another idea: master palettes could also be treated like local palettes pretty much everywhere, without need for special identity-map local palettes. (In particular spritesets directly indexing into the master palette.) It would be ideal if they could be referred to with normal local palette ID numbers, such as -2, -3, -4, ... (unfortunately palette -1 already means 'default palette for this spriteset'). The number scheme can be mostly hidden (eg by the UI in Custom), except when writing scripts, although masterpal:1 etc. constants or masterpalette(1) objects (new script interpreter) can be created to ease that.
The obvious way to handle existing local palettes is to extend them to 256 colours, but remaining local.
I feel forced to agree, though it seems icky.
They could be appear as variable length in the editors, up to a max of 256 colours, so that existing 16 colour palettes don't turn into unreasonable sizes automatically.

I can't see a much better alternative to handling existing local palettes, though there are some plausible ones (first point below). Here are a couple alternatives to having multiple master palettes and 256 colour local palettes:

* Leave local palettes limited to 16 colours and require that paletted sprites with more colours index directly into the/a master palette, but that means that palette swapping becomes master palette swapping. That wouldn't be so terrible if you can refer to master and local palettes with a single numbering scheme.

* Have just a single 256 colour master. If you want more colours, you have to use unpaletted sprites.

* A single master which is arbitrarily large. Local palettes and paletted sprites can use at most 256 colours from the master, this ensures that they can be exported as normal paletted image files, and then reimported without loss. The master palette could be displayed as 16x16 pages. When you import a paletted sprite you would have the option to remap it into a 256 (or lower) subset of the the existing master palette, or to add its colours onto the end (that could get really messy) or maybe tack on a new 256-colour page, as well as the existing option to remap to an existing local palette.
Palette editing commands can be restricted to ranges of the master palette (already exists for some).
Really, this is quite similar to having multiple master palette, but allowing local palettes to index into several of them.


In some places in the engine you specify a colour rather than a palette (eg text colours). In these cases they could all index into a single fixed master palette, "Default for text and menus".

'indirect palette' might be a better name than 'local palette'.
That's a bit much. Maybe a general option is needed? Certainly, if someone wanted to import in 24/32bit, and later convert to paletted as needed, then they would spend a lot of time selecting the exact same menu item.

Could it be broken down as follows:
* import either as 24/32bit or with new local palette
Possibly with a per-sprite-type default for which to do.
* separate operation to convert 24/32bit <-> local+master
* separate operation to remap local palette to existing master or existing local.
* (maybe) GC operation for master palettes -- delete unused ones.
Yes, it would be nicer to not show all the options at once. I hadn't even thought of remapping options shown in the graphics editors, that is, delayed quantisation. Importing with just a local palette is lossy, and it seems counter intuitive that if you want to import with a new master then you need to first import as 24/32. Instead I would first ask for paletted/unpaletted import, then if the former check whether lossless importing into the current (selected) local or current master is possible. Only if that fails do more options need to be shown. In fact that's already how it works, although it confused/surprised a couple people (even me) that the remapping options only appear sometimes, because it also affects whether you're asked to select a background colour (which gets remapped to colour 0).
On the other hand we already have this quite confusing UI for forbidding certain colours in the palette. I would like to get rid of it, but I fear it is useful.
Maybe I just use GrafX2 too much, but I find that UI simple.
Hah. I feel the placement of that menu is pretty bad: in the top level of options next to "append new backdrop" and "replace this backdrop". Better if the option is only presented when remapping is needed.
Last edited by TMC on Thu Oct 15, 2015 11:54 am, edited 4 times in total.
0ion9
Red Slime
Posts: 40
Joined: Sun Aug 02, 2009 7:45 am

Post by 0ion9 »

TMC wrote:Another idea: master palettes could also be treated like local palettes pretty much everywhere, without need for special identity-map local palettes. (In particular spritesets directly indexing into the master palette.) It would be ideal if they could be referred to with normal local palette ID numbers, such as -2, -3, -4, ... (unfortunately palette -1 already means 'default palette for this spriteset'). The number scheme can be mostly hidden (eg by the UI in Custom), except when writing scripts, although masterpal:1 etc. constants or masterpalette(1) objects (new script interpreter) can be created to ease that.
I think that is a pretty good scheme. The inconsistency of limits (max 32766 master palettes) is annoying but in practice I don't think anybody using the OHRRPGCE sanely would get bit by it.
* A single master which is arbitrarily large. Local palettes and paletted sprites can use at most 256 colours from the master, this ensures that they can be exported as normal paletted image files, and then reimported without loss. The master palette could be displayed as 16x16 pages.
If local palettes, as you imply below, are not to be limited to a contiguous 256-color 'tile' in the master palette, it might be better to take a page out of Grafx2 or Inkscape's book, and for example, scroll by half a page at a time to better maintain context.
When you import a paletted sprite you would have the option to remap it into a 256 (or lower) subset of the the existing master palette, or to add its colours onto the end (that could get really messy) or maybe tack on a new 256-colour page, as well as the existing option to remap to an existing local palette.
Palette editing commands can be restricted to ranges of the master palette (already exists for some).
Really, this is quite similar to having multiple master palette, but allowing local palettes to index into several of them.
Just to clarify, would this mean that local palettes would use a larger type to store indices (unsigned 16 bit)?. If so, this seems like the most seamless option.
In some places in the engine you specify a colour rather than a palette (eg text colours). In these cases they could all index into a single fixed master palette, "Default for text and menus".
Or in the one-master-palette scenario, there would be an indirect palette referencing those colors? Potentially a nice way to make global UI color setup simpler to understand.
'indirect palette' might be a better name than 'local palette'.
Yeah, actually GIF already uses 'local palette' for per-frame 'master palette's (though this is a pretty obscure feature)
Yes, it would be nicer to not show all the options at once. I hadn't even thought of remapping options shown in the graphics editors, that is, delayed quantisation.
Well, I think that is important because it allows the user to take a more considered approach. If we can do that without destroying data, it's good to do so.
Importing with just a local palette is lossy, and it seems counter intuitive that if you want to import with a new master then you need to first import as 24/32. Instead I would first ask for paletted/unpaletted import, then if the former check whether lossless importing into the current (selected) local or current master is possible. Only if that fails do more options need to be shown. In fact that's already how it works, although it confused/surprised a couple people (even me) that the remapping options only appear sometimes, because it also affects whether you're asked to select a background colour (which gets remapped to colour 0).
That seems like a bug... although I can totally understand why it would be a feature, too... ugh.

Custom could stand to have more OSD type stuff I guess. A simple message log.. Display the most recent message as a transparent overlay, have it time out eventually. I'm probably dreaming though.
Hah. I feel the placement of that menu is pretty bad: in the top level of options next to "append new backdrop" and "replace this backdrop". Better if the option is only presented when remapping is needed.
True.
Last edited by 0ion9 on Fri Oct 16, 2015 2:07 am, edited 4 times in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Just to clarify, would this mean that local palettes would use a larger type to store indices (unsigned 16 bit)?. If so, this seems like the most seamless option.
Yes. But the downside is that management of an indefinitely large master palette gets more complex. If there's one extra colour in an imported sprite, do you tack it on the end? Also, it means paletted sprites need to use 16 bit ints too if you want to be able to index into the master palette directly (as tilesets/backdrops already do). And if a spriteset uses more than 256 colours you can't export as an 8 bit image anymore. Are there common file formats which allow larger palettes?
Or in the one-master-palette scenario, there would be an indirect palette referencing those colors? Potentially a nice way to make global UI color setup simpler to understand.
You mean one master with >256 colours? Then you can index it directly. Or do you mean the in-use colours should be shown? That's basically what he UI Colors menu does. The colours used for UI are already indicated in the master palette menu, actually (some places where you can pick colours, such as the slice editor, aren't included, and it's just too much of a nuisance to include them)
... it also affects whether you're asked to select a background colour (which gets remapped to colour 0).
That seems like a bug... although I can totally understand why it would be a feature, too... ugh.
The idea is that if importing an 8 bit image and the master palette is identical, then you already have the palette you want, and aren't going to want to change it.
Custom could stand to have more OSD type stuff I guess. A simple message log.. Display the most recent message as a transparent overlay, have it time out eventually.
(Took me a while to work out OSD=On Screen Display) Reasonable, and seems like a good solution here. Also I think that tooltips would be a big improvement to many menus in Custom.
Last edited by TMC on Fri Oct 16, 2015 1:18 pm, edited 1 time in total.
User avatar
Nathan Karr
Liquid Metal Slime
Posts: 1215
Joined: Fri Jan 25, 2008 3:51 am
Contact:

Post by Nathan Karr »

My best results come from master palettes of 16-32 colors.
Remeber: God made you special and he loves you very much. Bye!
0ion9
Red Slime
Posts: 40
Joined: Sun Aug 02, 2009 7:45 am

Post by 0ion9 »

TMC wrote:
Just to clarify, would this mean that local palettes would use a larger type to store indices (unsigned 16 bit)?. If so, this seems like the most seamless option.
Yes. But the downside is that management of an indefinitely large master palette gets more complex. If there's one extra colour in an imported sprite, do you tack it on the end? Also, it means paletted sprites need to use 16 bit ints too if you want to be able to index into the master palette directly (as tilesets/backdrops already do). And if a spriteset uses more than 256 colours you can't export as an 8 bit image anymore.
Ah, that would be my mistake, I thought we were using the premise that a palette was per spriteset.
Are there common file formats which allow larger palettes?
Not that I know of. PNG which I otherwise would have picked as the most likely candidate, explicitly says that bit depth of pixels in indexed images shall be 1,2,4, or 8.
You mean one master with >256 colours? Then you can index it directly. Or do you mean the in-use colours should be shown? That's basically what he UI Colors menu does.
Yes, I know. I'm really just expressing the idea that if UI colors 'menu' could be made more similar to indirect palette editing, it would be more familiar / easy to approach. Which probably isn't true actually.
The idea is that if importing an 8 bit image and the master palette is identical, then you already have the palette you want, and aren't going to want to change it.
Oh okay, I was thinking of a 24bit image that you want to import paletted, and all the colors exist in the master palette.
(Took me a while to work out OSD=On Screen Display) Reasonable, and seems like a good solution here. Also I think that tooltips would be a big improvement to many menus in Custom.
No argument there.
Nathan Karr wrote:My best results come from master palettes of 16-32 colors.
I agree. It's much easier to make interesting use of color when your choice is limited. I notice no-one has posted Arne's 16color palette, 64col palette, or Dawnbringer's 16col palette or 32col palette yet; the latter two are definitely public domain.
Last edited by 0ion9 on Fri Oct 16, 2015 11:06 pm, edited 2 times in total.
User avatar
Nathan Karr
Liquid Metal Slime
Posts: 1215
Joined: Fri Jan 25, 2008 3:51 am
Contact:

Post by Nathan Karr »

0ion9 wrote: I agree. It's much easier to make interesting use of color when your choice is limited. I notice no-one has posted Arne's 16color palette, 64col palette, or Dawnbringer's 16col palette or 32col palette yet; the latter two are definitely public domain.
I've never heard of either of those people or any of their palettes. I've mostly been using the one (TwinHamster I think it was?) posted as a rule for a contest which never got off the ground shortly before the first 8-Bit Contest.
Remeber: God made you special and he loves you very much. Bye!
0ion9
Red Slime
Posts: 40
Joined: Sun Aug 02, 2009 7:45 am

Post by 0ion9 »

Nathan Karr wrote:
0ion9 wrote: I agree. It's much easier to make interesting use of color when your choice is limited. I notice no-one has posted Arne's 16color palette, 64col palette, or Dawnbringer's 16col palette or 32col palette yet; the latter two are definitely public domain.
I've never heard of either of those people or any of their palettes. I've mostly been using the one (TwinHamster I think it was?) posted as a rule for a contest which never got off the ground shortly before the first 8-Bit Contest.
Well, have some links:

* Arne's 16c : pixelation thread
* Arne's 16c, 32c, and others: page on arne's site; at the bottom there is a nice table of the different palettes. 'CPCBoy' interests me. The palette known as 'Arne's 64c' appears to be the one labelled 'Famicube' on this page.
* Dawnbringer's 16c; very carefully balanced and checked.
* Dawnbringer's 32c -- I use this all the time myself, not only in pixel art.

Also I just checked up on 'licensing' (like I said, just to be safe, even though palettes probably don't qualify for copyright):

Arne's 16c is explicitly free for whatever use you want, as is DB16 and DB32.

Arne's 32c and some of the other palettes on his page above have an ambiguous status, but I'd be happy to talk to Arne and clear that up if need be -- I'm pretty sure he'd be fine with it.
Last edited by 0ion9 on Sat Oct 17, 2015 4:05 am, edited 1 time in total.
Post Reply