54 replies to this topic

[fusion_power]

@ 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.

Edited by fusion_power, 18 July 2007 - 05:09 PM.

[rokdcasbah]

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.

[A_SN]

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..

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.

Edited by A_SN, 18 July 2007 - 07:51 PM.

[xythen]

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).

Edited by xythen, 18 July 2007 - 08:58 PM.

[kevcal]

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...

Edited by kevcal, 18 July 2007 - 09:05 PM.

[fusion_power]

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 .

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.

Edited by fusion_power, 18 July 2007 - 09:28 PM.

[rokdcasbah]

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.

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

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.

Edited by rokdcasbah, 19 July 2007 - 02:56 AM.

[A_SN]

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

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...

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

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

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.

Edited by A_SN, 19 July 2007 - 08:38 AM.

[rokdcasbah]

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?

[A_SN]

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.

[Alex.]

Why not use SDL_image? SDL ain't poison you know

[A_SN]

Why not use SDL_image? SDL ain't poison you know

Nah, I've used SDL_image before and had issues with it, mainly had issues with it working on a platform and not on another and such, and then i'm not comfortable with SDL.

[rememberthe8bit]

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

Yeah, I noticed this too. It looks more grey-ish, like my Phat DS compared to a lite DS.

I voted "No" on the poll, but the concept is a great idea. Perhaps you should add a command line interface, too.
(I'd like to add it, myself, but I can't seem to figure out how do do that... Oh well. )

[Ryo]

It seems a lot of users find this useful, so I could actually look into integrating it in gmenu2x if there is demand for such a feature.
I have a MKI though and I am happy with it so I wouldn't directly benefit from this
I would also have to look into having this coexist with the gamma settings (or removing them)

[A_SN]

It seems a lot of users find this useful, so I could actually look into integrating it in gmenu2x if there is demand for such a feature.
I have a MKI though and I am happy with it so I wouldn't directly benefit from this
I would also have to look into having this coexist with the gamma settings (or removing them)

But before we could integrate it to gmenu2x or anything else we'd have to find a way to tell MKI's from MKII's. Would you know how?