Creating pixel art

Page 15/33
8 | 9 | 10 | 11 | 12 | 13 | 14 | | 16 | 17 | 18 | 19 | 20

By Grauw

Ascended (8378)

Grauw's picture

27-01-2018, 15:20

Afaik they were measured, but you’ll have to ask them or search the bug / mail archives for mention about it.

The V9938 application manual on the 4th page of the PDF also says “linear RGB video output”.

By sd_snatcher

Prophet (3047)

sd_snatcher's picture

28-01-2018, 15:46

Ok. It would be nice to know the real values for sure.

I have some GIMP palettes that I created, and I would like them to have the closest possible values to the real thing, to avoid distortion:

MSX2_SCR8.gpl
MSX2_default.gpl (default 16 color palette)
MSX2_RGB9.gpl: The complete set of 512 colors from the MSX2
MSX2+_SCR10.gpl: All 12499 YJK colors available in this mode

I have used the rule of three to scale the MSX2 RGB9 (and MSX2+ RGB15) to RGB24 linearly. I noticed that many MSX image converters seem to use this method. But I'm not sure it it's the best one, specially considering that modern computers feature the sRGB color space, that isn't linear and has some built-in gamma correction.

Probably the authors of MSX image conversion tools would be interested to know the answer too, so if someone knowledgeable of this topic could shed a light here, it will be welcome.

By Grauw

Ascended (8378)

Grauw's picture

28-01-2018, 16:34

I was pretty elaborate in my earlier post, could you be specific what you want to know more about?

The palette values I gave earlier are already including gamma correction to sRGB, tho it’s a bit of an estimate since various sources quote different CRT gammas, I stuck to using the same gamma correction as openMSX.

By sd_snatcher

Prophet (3047)

sd_snatcher's picture

02-02-2018, 18:36

Before replying this, I caught myself wondering how I could explain my doubt, without going TL;DR or sounding authoritative. Here goes my best try.

First, I would like to thank you for the details about how the V9938 maps the 3bit values to 7bits, and how the V9958 maps the 3bit values to 5bit. That helped with some issues I've had until now, specially in screen-8.

Also, please keep in mind I'm by no means a specialist in this topic, ok?

If I understood your explanation correctly, the idea is to discover the correct sequences to build palettes for the Graphic editors, right? Like, for example, to create a GIMP .gpl palette file. Such palette files have a variety of uses, from directly drawing on some Graphic Editor to just converting RGB24 images to a indexed palette (like MIFui does).

As you said, the V9938 datasheet states that it outputs linear RGB9. And the V9958 outputs linear RGB15 (with some kinky RGB9->RGB15 conversion for the RGB9 colors)

A linear sequence has evenly spaced elements. This means that:

- 3bit expanded to 8bit means 7 intervals evenly spaced between 255 values. So, the distance between each point is 255/7 = 36.429. When rounded to the closest integer values, this linear sequence would then be: 0, 36, 73 ,109, 146, 182, 219, 255
- 5bit expanded to 8bit means 31 intervals evenly spaced between 255 values. So, the distance between each point is 255/31 = 8.226. When rounded to the closest integer values, this linear sequence would then be: 0, 8 ,16, 25, 33, 41, 49, 58, 66, 74, 82, 90, 99, 107, 115, 123, 132, 140, 148, 156, 165, 173, 181, 189, 197, 206, 214, 222, 230, 239, 247, 255

Then comes the dilemma on whether to embed a gamma correction in the palette or not.

From what I have read until now, palettes always should be linear, and any color management should be left to the application, and executed only as a presentation layer. For example, both the Gimp and Photoshop do this. And must be possible to disable the color management and see the images with raw linear values.

And even openMSX does it: the screenshot console command saves an image file in presentation mode (internally color managed, plus stretch and effects like scanlines). But if you add the -raw parameter, it saves an image file without the presentation layer. This means linear color values and no effects at all.

If the gamma correction is embedded in the palette, the images produced with this palette will appear to be darker when presented in applications that have a color management, or on the real MSX+CRT monitor, as CRTs have a built-in natural gamma correction curve.

Aseprite, for example, has no built-in color management. This causes the users to pick brighter colors that will look better in their LCD displays. Then the darker image problem happens when such images are loaded on Photoshop or real retro computers with CRTs, as shown in the links below:
https://community.aseprite.org/t/colors-displaying-different...
https://github.com/aseprite/aseprite/issues/1576

Because all of this, it seems that the linear mapping of the MSX values to RGB24 values is more advisable. What do you think?

By Grauw

Ascended (8378)

Grauw's picture

04-02-2018, 01:21

You’re not correct in saying palettes should always be linear. There’s no such rule or recommendation.

Most of the time images are encoded with gamma information embedded in the colours. The oft-used sRGB is a prime example of that, it just standardises the amount of gamma applied, but it is far from linear (even the gamma formula is more complicated than just a simple power). The reason sRGB exists and people aren’t just saving colours linearly is that sRGB gives the artist higher colour resolution in the parts that matter.

Some images are saved with external gamma information (note the image itself may still have gamma -e.g. sRGB- and is not necessarily linear). This generally applies to the more professional branches of image editing, where one would also e.g. store their images with 16-bits per colour component to preserve resolution. Note even at my work the artists don’t do much with gamma though.

So this is just a matter of the storage encoding. You can convert from the one to the other. The images won’t show darker in editors with colour management, unless a gamma chunk was incorrectly embedded as well which would result in double gamma compensation.

In the end you want to be editing on your PC in the same colours that will be shown on the MSX (be it emulated or real). Whether you’re doing that with the colour values pre-corrected to common PC gamma I presented earlier, or you’re using linear values and applying a gamma correction chunk is up to you.

The former is more straightforwardly useful, the latter takes more explanation, but I gave sufficient information (about gamma being applied and how much of it) so that those who are aware of the intricacies of gamma management are able to have a set-up of their liking. I think having external gamma is more likely to cause issues with or unnecessarily restrict your choice of tools though.

By Grauw

Ascended (8378)

Grauw's picture

04-02-2018, 01:42

So as for tools. Fact is there are a lot of tools that don’t deal with external gamma information. Usually the tools which have extended support for this lean to the expensive professional side. So this can be a reason to not use separately specified gamma information.

(As for Aseprite, afaik it does read gamma chunks correctly, so the colours stay intact, but it doesn’t save it. Btw, if I may make an anti-recommendation, steer clear of Pixen for MacOS, it makes a total mess of gamma and doesn’t save images with the same colours you edited them with.)

For image conversion tools to MSX, a “correct” conversion tool would take both the entire image gamma information and CRT gamma into consideration. These would convert images stored in whatever way correctly.

In the presence of more naive tools which ignore external gamma chunks, a tool which converts colours linearly would produce correct results when the palette is also linear. However that kind of tool would in general result in images being too dark compared to what you see on PC, so that seems unlikely to me. If the tool converts colours on a CRT-like gamma scale, it will produce the correct results when provided with a gamma pre-applied into the colours.

Note that for 3-bit palette colours, whichever of the two you feed into it, due to rounding the results will be the same just as long as you stick to the exact values on the scale.

Anyway, pre-applied gamma works for me, but as it’s just a matter of tools and encoding, all I can say is experiment with it. All that matters is that the image you’re editing and the output of the MSX look the same.

And not taking CRT gamma into account at all will not give great results, as I learned when making the Rose image, which I edited with linearly spaced sRGB colour values at first, and ended up looking different in the emulator and real MSX than it did in the editor Smile.

By Grauw

Ascended (8378)

Grauw's picture

04-02-2018, 02:09

And after all this talk, most people will still be wondering “but what is gamma, then?” “Is it that colours get brighter?” Well, no, not exactly. “Is it that colours get darker?” Well, not either, it’s more of a curve, that depending on the source and target gamma space changes the spacing of the darker and brighter colours. I could give you the transfer function… pow(pow(colour / range, source_gamma), 1 / target_gamma) * range, or pow(colour / range, source_gamma / target_gamma) * range, and PC gamma is approximately 2.2 while CRT gamma is approximately 2.4. “Confused looks Question.” Ok, just use these values Hannibal.

By Rydeen

Supporter (5)

Rydeen's picture

19-03-2018, 07:33

This is a long thread and I don't ant to scroll through all 15 pages to find answers, but can somebody tell me what is the preferred Graphics tool for MSX2? Like what was popular in the Japanese MSX-enthusiast community in the 80's? What was being used for submissions to magazines like MSX Fan and MSX Magazine?

By Grauw

Ascended (8378)

Grauw's picture

19-03-2018, 08:24

T&E's DD-Graph AGE5 is the best imo, many people also like Bit2's Graph Saurus.

Funny that these were both game companies :D.

By ro

Guardian (4109)

ro's picture

19-03-2018, 10:09

Ditto on AGE5, it's a heck of a tool. simple, elegant and fast. get's the job done.

Page 15/33
8 | 9 | 10 | 11 | 12 | 13 | 14 | | 16 | 17 | 18 | 19 | 20