Lcd Colour Correcting Daemon For Mkii's

Do you like it?

  • Yes

    Votes: 0 0.0%
  • I can't see what it does, looks just the same as before to me

    Votes: 0 0.0%
  • No

    Votes: 0 0.0%

  • Total voters
    0

A_SN, I gave it a try some more, and I came to the conclusion that your calibration could stand to be a bit more saturated. Not as much as the MK2 default, but a bit nonetheless. Right now it's too close to looking washed out. Besides, a bit more saturation will lower the gap between graphics that look best on MK2 and their change after calibration :)
 
Megagun said:
Excuse me, but I haven't yet tried it.. :/
Still got a suggestion/idea though.. :)

Anyways, can you perhaps make another program that handles gamma settings "properly"? The ones that are available right now seem.. weird. I set gamma to pretty damn low, and it seems that when I watch movies that have plenty of contrast, the dark stuff gets black, the lightish stuff gets darkened slightly, and the white stuff just stays white.

Personally, I'd really love an advanced LCD screen output modifier, since.. well... it'd be great. :)

Maybe your program already does this, at which case, you can slap me in the face right now..

edit: tested it, and it seems to ruin GMenu2x's inbuilt gamma settings. :/
As of now it's designed only to correct the non-linearity of the colours on the MKII's screen, but I guess we could imagine it having a gamma and a contrast setting on top of that.

And yes, it'll ruin gmenu2x' gamma settings.

Alex. said:
A_SN, I gave it a try some more, and I came to the conclusion that your calibration could stand to be a bit more saturated. Not as much as the MK2 default, but a bit nonetheless. Right now it's too close to looking washed out. Besides, a bit more saturation will lower the gap between graphics that look best on MK2 and their change after calibration :)
Unlike what you seem to think, my tool has no direct impact on saturation whatsoever but rather on contrast. It works just like Photoshop's curves tool. But I'll later consider adding a customized gamma and constrast setting for people to set to their liking. There's strictly nothing I can do about saturation.
 
Last edited by a moderator:
A_SN said:
fusion_power said:
Hey, interesting thing! :) I had made some skins and graphics for a few GP2X Games and I had to spend hours and Hours to correct the colours of the graphics to match the appearence on GP2X with the PC Screen, often 2 completely different things. ^^""
At the end the corrected colours looked stupid on PC screen but ok on GP2X (MK2) Of course this is far away of modern WYSIWYG (what you see is what you get)
Interested, you're the proof that Alex was right about people making games for the MKII. Well, if you want to revert colours to the way they were meant to be, I think you can do that with the Curves in Photoshop by setting the 3 following dots like this :

In : 64, Out : 42
In : 128, Out : 115
In : 192, Out : 208

Haven't tested, but it should do the opposite as colourd (the daemon discussed here) does, which means make things look on your PC as they do on your GP2X


Yes, should be tested maybe.
I had tested the app with some games and Emulators, everything looks much better now. For Example, in SQDef, the big shots of the super Tower don't look white any longer. They are now look pink as they should be. :) But for Videos, I like the standard Setting of the MK2 screen. Especially Cartoons and Animes looks better with the harder contrast in the colors and the darker black and the brighter white. Actually I use similar post processing filter settings on my PC to boost the Images of Videos. So Light really blends you and Black is really black. I wouldn't watch BSG without it. :)
 
Last edited by a moderator:
fusion_power said:
Yes, should be tested maybe.
I had tested the app with some games and Emulators, everything looks much better now. For Example, in SQDef, the big shots of the super Tower don't look white any longer. They are now look pink as they should be. :) But for Videos, I like the standard Setting of the MK2 screen. Especially Cartoons and Animes looks better with the harder contrast in the colors and the darker black and the brighter white. Actually I use similar post processing filter settings on my PC to boost the Images of Videos. So Light really blends you and Black is really black. I wouldn't watch BSG without it. :)
Basically, I think that what the MKII does to colours can be summed up like this, a gamma < 1.0 (1.0 being the right thing) and a higher contrasts than it should have. I'll consider including customizable gamma and contrast settings, also maybe luminosity, and I'll try to think up a way to set such things on a per-app basis, or maybe someone else will because at that point I won't be arseable to do that kind of crap that I don't personally need ;)
 
Last edited by a moderator:
A_SN said:
I'll consider including customizable gamma and contrast settings, also maybe luminosity, and I'll try to think up a way to set such things on a per-app basis, or maybe someone else will because at that point I won't be arseable to do that kind of crap that I don't personally need ;)
It's a perfect thing for the link-settings of Gmenu2X I think. So the correction can be enabled and disabled per game. You should talk with Ryo, maybe he includes it in the next release of the menu. :)

Here, I had made an Example Pic, comes close to the original GP2X screen I think. I just used an out value of 216 instead of 208 at the last curve dot.

left is the standard MK2 LCD on screen appearence, right Pic is the normal PC appearence and the GP2X look after the correction with the tool. I think it depends of the personal taste of the users which setting is prefered.
colourcfu4.png
 
Last edited by a moderator:
I came upon an issue, although it may be an indirect issue. After I run colour.gpe, and I connect the GP2X's SD to USB, it works fine, but when I want to disconnect it hangs there (the connection is terminated though, it's just that it doesn't show it). I tried it twice, so it couldn't have been a coincidence ;)
 
Alex. said:
I came upon an issue, although it may be an indirect issue. After I run colour.gpe, and I connect the GP2X's SD to USB, it works fine, but when I want to disconnect it hangs there (the connection is terminated though, it's just that it doesn't show it). I tried it twice, so it couldn't have been a coincidence ;)

I don't know all I can tell is that colourd keep running until you shut your gp2x down so it may be why. A SD isn't such a great place for a daemon anyways ;)

@ fusion power : here's the correctly done before-after comparison (no idea why you used 216, looks pretty much the same tho, just had to make sure)

[attachmentid=330]
 
Last edited by a moderator:
fusion_power said:
left is the standard MK2 LCD on screen appearence, right Pic is the normal PC appearence and the GP2X look after the correction with the tool. I think it depends of the personal taste of the users which setting is prefered.
Yes, certainly some games/emulators/cartoons might benefit from the mk2 screen (aside from the very narrow viewing angle). In particular, emulators of old systems that could only display a handful of colors anyway doubtless look more vibrant with the unnaturally high contrast. And I'll admit that in the game you picked for your illustration, I prefer the untweaked version, except for artifacts like the pink color simply being shown incorrectly. That interface uses brightly colored high contrast graphics anyway, and looks great without tweaking.

What bugs me about the mk2 default is pictures of things like a bright green sphere with a nice specular highlight. On a PC screen it looks great, but the highlight area tends to turn into a massive undistinguished blob of "brightest possible color" on the mk2 gp2x screen. When I was a kid we had an analog TV with a "contrast" knob on it; my young aesthetic tastes were such that I would crank the contrast up because I liked the bright cartoony look it gave everything. My old-fogey tastes are different, but this is yet another case where the gp2x is "your misspent youth in a box"!

Whether individual homebrew authors use it in their software when it is effective to improve their programs, or whether it's a user-choice general purpuse utility or feature of a system shell, I think this is a great leap forward for the gp2x community. Thanks again A_SN!
 
Last edited by a moderator:
A_SN said:
Critical_Impact said:
Shouldn't it just be?

CODE
#!/bin/sh
cd /mnt/sd/gmenu2x
exec ../App/colourd_070717/colourd.gpe
exec ./gmenu2x

CODE
#!/bin/sh
cd /mnt/sd/gmenu2x
exec ../App/colourd_070717/colourd.gpe&
exec ./gmenu2x



actually


i tried taking out the ./gmenu2x (since the fix loads it anyways) but the gp2x never loaded.
then i tried the above, and now the gp2x is freaking out... its randomly switching between all the icons on the screen, as if i was holding down the right/left directional.
 
Last edited by a moderator:
A_SN said:
@ fusion power : here's the correctly done before-after comparison (no idea why you used 216, looks pretty much the same tho, just had to make sure)

[attachmentid=330]
maybe 232 is better to. It's just for the big bullets of the Super Tower, they look whiter this way I think and on GP2X they look really white. This would be the only positive benefit by the way like Dzz mentioned: cortrect pink colours of the bullets instead of white. I like the stronger colours of the default setting to in SQDef, I know Alex had changed the graphics to look best on MK2 screens so the Colour Fix is not needed for SQDef.
But for Example Picodrive or GNGeo or all the emulators benefit extremely from the tweak IMHO. :)
 
Last edited by a moderator:
damn. i had no idea there was such a difference (the ones on the right pretty much match what i see on my mk1). that's really annoying...i'm looking at the stuff i'm doing now and it looks terrible with the a_sn's mk2 curve applied. but if i fix it, it'll look terrible on mk1s. and there's no point in waiting. this is really frustrating.

the ISP lets you set whatever you want: gamma correction, brightness, contrast, edge detection...once it becomes YUV you can set luma & chrominance. plus there's clipping thresholds for luma & chroma, signal delay tweaks, etc. the bottom line is that gph set the default gamma wrong for these screens and probably did so because it looks more saturated that way. one more reason why an open firmware is going to rock.

a_sn, i think it would be really cool to see this daemon with an interface that shows a sample image and lets you adjust a slider. i haven't used it yet (at work) so if it does something like this then tell me to shut up. also, does data always pass through the ISP, and always end up as YUV? if that's the case, would messing with the chrominance regs be useful at all?

alex: it's going to be less saturated because of the way the curve is going (towards less contrast). i'm racking my brain as to explain why specifically but i really can't.*

* i suspect it's because the most saturated-looking colors an electronic display can do are R,G,B,C,Y,M. any shade of those will approach white or black. white and black have no hue or saturation. BUT technically we can't say that gamma correction is like changing luma. you can only figure out the luma once you take the gamma compressed rgb values. gamma is about voltage, not color space.

that said, my rough feeling is that, even though some blown out light colors could gain saturation (maybe?), the mid-range and darker colors are losing it.
 
Last edited by a moderator:
fusion_power said:
maybe 232 is better to.
Well maybe, but we'll decide on that when my test will be released and that we'll share the results each of us have found. I could also possibly have a test involving more than 3 points maybe, the problem is, the more points you put the less the curve will be smooth and the more it'll be jittery, but I could try that..

rokdcasbah said:
a_sn, i think it would be really cool to see this daemon with an interface that shows a sample image and lets you adjust a slider. i haven't used it yet (at work) so if it does something like this then tell me to shut up. also, does data always pass through the ISP, and always end up as YUV? if that's the case, would messing with the chrominance regs be useful at all?

alex: it's going to be less saturated because of the way the curve is going (towards less contrast). i'm racking my brain as to explain why specifically but i really can't.*

* i suspect it's because the most saturated-looking colors an electronic display can do are R,G,B,C,Y,M. any shade of those will approach white or black. white and black have no hue or saturation. BUT technically we can't say that gamma correction is like changing luma. you can only figure out the luma once you take the gamma compressed rgb values. gamma is about voltage, not color space.

that said, my rough feeling is that, even though some blown out light colors could gain saturation (maybe?), the mid-range and darker colors are losing it.
What's an ISP, besides an internet service provider? anyways, the way colours are corrected is based on an optical test, this is based on science. If we trusted people to decide what looks best, we would end up with something over contrasted and with a pretty big gamma.

The scope of my daemon is to provide nearly linear shades of grey on the MKII's, I'm getting tired of hearing how people want to crank out the contrast and such. I could have brought you a perfect magical fix to this old problem, which is almost what I came up with, and you guys would still want to go back from time to time to the old cranked up display and worse, fiddle around with a crapload of other settings to make your own unique cranked up settings.

So no, there wont be a slider to fiddle with whatever luma might be. I'll keep it all simple and to the point, while trying to make everyone who knows what they need and don't need, satisfied to a certain degree.
 
Last edited by a moderator:
Just wanted to say this is an excellent little app! I've been testing it out with gpfce and the image looks infinitely better. Much more balanced and natural looking! :)

One thing I've found; when exiting gpfce (v0.4 r171, ie the newest version) it returns to the default settings at the gp2x menu, then after ~3 seconds the screen switches again to the new settings. It's actually quite a useful bug since it lets you see an obvious "before & after" transition, but it only seems to happen with this emulator (I tried picodrive and some gbax entries and nothing else seemed to do it).
 
xythen said:
Just wanted to say this is an excellent little app! I've been testing it out with gpfce and the image looks infinitely better. Much more balanced and natural looking! :)

One thing I've found; when exiting gpfce (v0.4 r171, ie the newest version) it returns to the default settings at the gp2x menu, then after ~3 seconds the screen switches again to the new settings. It's actually quite a useful bug since it lets you see an obvious "before & after" transition, but it only seems to happen with this emulator

This sounds great - I hate the difference between running my code in a kde window and then being so dark on the gp2x.
Anyway, I believe it resets the table every 5 seconds.. hence what you see happening.
When this is considered an important add-on - I think it is - then maybe it can be run some other way - ie not a s a daemon but hhoked into open2x o/s possibly?
It could also be optimisedup a bit more if necessary (at the expense of a little memory). Actually probably straightfoward for someone to convert to assembler?

EDIT: damn my typing is bad tonight - too tired to fix...
 
Last edited by a moderator:
A_SN said:
fusion_power said:
maybe 232 is better to.
Well maybe, but we'll decide on that when my test will be released and that we'll share the results each of us have found. I could also possibly have a test involving more than 3 points maybe, the problem is, the more points you put the less the curve will be smooth and the more it'll be jittery, but I could try that..

No, my value was just for my example pic to see the difference better. When you say, your values are good, I trust you. I only changed the value by viewing and comparing the pic by eye-measurement at my (crappy adjustet) CRT Monitor . :)


xythen said:
One thing I've found; when exiting gpfce (v0.4 r171, ie the newest version) it returns to the default settings at the gp2x menu, then after ~3 seconds the screen switches again to the new settings. It's actually quite a useful bug since it lets you see an obvious "before & after" transition, but it only seems to happen with this emulator (I tried picodrive and some gbax entries and nothing else seemed to do it).
It happend with every application I tried, picodrive to I think. After exiting, Gmenu2x shows his standard Colours and then, the fix, well, fix it. But it's no problem, I can live with that.
 
Last edited by a moderator:
A_SN said:
What's an ISP, besides an internet service provider? anyways, the way colours are corrected is based on an optical test, this is based on science. If we trusted people to decide what looks best, we would end up with something over contrasted and with a pretty big gamma.
sorry, that's what the data sheet calls it for short. i should have used the right name.

QUOTE
The Image Signal Processor (ISP) of the MP2520F receives 6 types of Input format. It Gamma corrects using a RAM. It enhances Luminance by adjusting Contrast, Brightness and Edge, and enhances Chrominance by adjusting Hue and Saturation. In addition, it has functions for Clipping, Suppress. Finally, it provides Clocks or Syncs to external Image


the thing is, our eyes don't respond to light linearly. plus it differs among individuals, time of day, etc. that said, i understand your feeling completely. your work doesn't affect me on the user side (mk1), but i'm really hoping that everyone adopts this, and figured that if it was adjustable people wouldn't complain about it being too extreme, and i wouldn't have to worry about designing for two different gammas.

i won't pretend that's not selfish :D

in any case, it's great work and must have been an exacting process getting the test values, and it's of course appreciated.

ps. am i wrong about gph setting a bad default gamma correction? did they just not set any at all? in your code you have to change the register to turn on the gamma control, so i guess maybe they just used the screens as-is. still lame and still a problem for homebrew at least.

edit: i forgot something. actually, it does affect me as a user. because i want to crank up the chroma on mine. well, the source is in there, so i'd better get off my lazy butt.
 
Last edited by a moderator:
xythen said:
One thing I've found; when exiting gpfce (v0.4 r171, ie the newest version) it returns to the default settings at the gp2x menu, then after ~3 seconds the screen switches again to the new settings. It's actually quite a useful bug since it lets you see an obvious "before & after" transition, but it only seems to happen with this emulator (I tried picodrive and some gbax entries and nothing else seemed to do it).
I guess it means that gpfce changes the registers used by colourd to normal when exiting (maybe does it do it too when you start it?) which is why I made the daemon write the values again and again to the registers every 5 seconds. So yeah, it's a feature, not a bug ;)

kevcal said:
When this is considered an important add-on - I think it is - then maybe it can be run some other way - ie not a s a daemon but hhoked into open2x o/s possibly?
It could also be optimisedup a bit more if necessary (at the expense of a little memory). Actually probably straightfoward for someone to convert to assembler?
Well even if it is in open2x (and it will be) it'll still be a daemon ;). why optimise it? what it does every 5 seconds seems to take about 1500 cycles, and if I'm not making any mistake at 200 MHz that'd be about 7.5 µs. 0.0000075 seconds wasted every 5 seconds, does it sound like it requires optimization? Oh well that's if I compile it with -O2 tho, which I haven't done yet. I'll do it next time. Oh and actually I don't think there'd be much to optimize in assembly anyways, that's the kind of code gcc is great at optimizing. As for memory usage, it doesn't take much more than a hello world, besides a 768 B array...

fusion_power said:
It happend with every application I tried, picodrive to I think. After exiting, Gmenu2x shows his standard Colours and then, the fix, well, fix it. But it's no problem, I can live with that.
Yes, because gmenu2x tries to apply its gamma setting. I guess I could "fix" more often than every 5 seconds then. I'll have to do some fiddlings with that ;)

rokdcasbah said:
the thing is, our eyes don't respond to light linearly. plus it differs among individuals, time of day, etc. that said, i understand your feeling completely. your work doesn't affect me on the user side (mk1), but i'm really hoping that everyone adopts this, and figured that if it was adjustable people wouldn't complain about it being too extreme, and i wouldn't have to worry about designing for two different gammas.

i won't pretend that's not selfish :D

in any case, it's great work and must have been an exacting process getting the test values, and it's of course appreciated.

ps. am i wrong about gph setting a bad default gamma correction? did they just not set any at all? in your code you have to change the register to turn on the gamma control, so i guess maybe they just used the screens as-is. still lame and still a problem for homebrew at least.

edit: i forgot something. actually, it does affect me as a user. because i want to crank up the chroma on mine. well, the source is in there, so i'd better get off my lazy butt.
While our eyes maybe not respond to light linearly, we expect to see stuff that's linear wrt real world stuff.

As for getting the test values, well it's based on an easy test actually. The only hard thing is that I didn't go that way in the first place, made another test that gave utterly bogus results.

And as for GPH, they just didn't turn colour correction on, and we can't blame them for that, although ideally they would have used that to calibrate their lcds.
 
Last edited by a moderator:
A_SN said:
we can't blame them for that
let's do it anyway.

offtopic: the arse is pretty cool. ever just renamed a wav to *.raw and opened it in photoshop? actually it's not that great.

also offtopic: have you done anything else recently that involved your random dither work?
 
Last edited by a moderator:
rokdcasbah said:
A_SN said:
we can't blame them for that
let's do it anyway.

offtopic: the arse is pretty cool. ever just renamed a wav to *.raw and opened it in photoshop? actually it's not that great.

also offtopic: have you done anything else recently that involved your random dither work?


lol thanks, but why would you want to import a .wav as an image? :)

as for the random dithering thing, I haven't done anything new yet, but I was considering making a basic picture viewer including that for I am tired to see banding on my porn, lol, but I don't know how to open .jpeg pictures... file I/O is always an issue when trying to do such things.
 
Last edited by a moderator:
Back
Top