I am sharing the source code for the GUI editor I created, that has the revolutionary built-in colour picker. I am not sharing it in order to make it into a communal project (but if anyone has any non-neatness-related revolutionary changes to it, I will certainly integrate them into EDP), but in order to solve the Avatar problem.<br>
<br>
I got the following information from <a href="https://forums.frontier.co.uk/showthread.php?p=3908733&viewfull=1#post3908733" target="_blank">this link</a> (thanks to <a href="https://www.youtube.com/user/MacGuire31" target="_blank" rel="nofollow">Caointean</a>) where Matt hints that they apply the inverse matrix to the avatars to normalise them. The information loss in that process is the cause of some avatars being miscoloured. <br>
<br>
So I created the code that does exactly that, but the problem is, the result isn't quite the same. It seems to be the same in a lot of cases, but not all.<br>
<br>
The problem is the information loss, both the game and this app suffer from it. When a pixel's colour channel gets transformed to a value over 255, it gets normalised to 255 (same on the zero end). When the inverse matrix is applied, the value will return to a lower value than it started out with. <br>
<br>
In my app, this will lead to the colours not being right. However, in my app, sometimes most of the colours are ok, but the places that are really quite bright, like the cheeks of Dr. Kaii, become splotchy in certain cases. If I then load that GUI combo into the game, the game won't have that splotchiness. <br>
<br>
Weirdly too, sometimes the game will be fine with it, sometimes not. Also, some profiles don't match what the game does to their avatars at all. So basically, I'm on the right lines, but not doing it quite right.<br>
<br>
Confounding this further is that some matrices don't have an inverse (the determinant is zero), so my program just exits the sub at that point, but Frontier's code still does something. So clearly they aren't just applying the inverse matrix.<br>
<br>
So yeah, I have pmed Matt, I have even opened a support ticket. They are very busy so I doubt I will get a resolution to this, so I am opening it to the community, especially the math boffins and the digital color experts. <br>
<br>
There is a commented out part of my code that deals with the inverse matrix directly (I did that, foolishly, to try it without the information loss, but of course that leads to perfect avatars 100% of the time, but I've kept it as it might come in useful for whatever weird process Frontier are using). You can either explain to me what you think they are doing and I will happily write the code myself to test, or you can use the source below to try it out yourself. If you get something workable, share it and I will reintegrate with EDProfiler and the community will rejoice <img src="https://forums-cdn.frontier.co.uk/images/smilies-frontier/smile.png" border="0" alt="" title="Smile" smilieid="70" class="inlineimg"><br>
<br>
Credit will be given of course. <br>
<br>
<br>
<a href="https://goo.gl/AtcyBS">Source Code.</a><br>
*Don't forget to add the EDProfiler folder to "My Documents" for the built-in profiles
<br>
I got the following information from <a href="https://forums.frontier.co.uk/showthread.php?p=3908733&viewfull=1#post3908733" target="_blank">this link</a> (thanks to <a href="https://www.youtube.com/user/MacGuire31" target="_blank" rel="nofollow">Caointean</a>) where Matt hints that they apply the inverse matrix to the avatars to normalise them. The information loss in that process is the cause of some avatars being miscoloured. <br>
<br>
So I created the code that does exactly that, but the problem is, the result isn't quite the same. It seems to be the same in a lot of cases, but not all.<br>
<br>
The problem is the information loss, both the game and this app suffer from it. When a pixel's colour channel gets transformed to a value over 255, it gets normalised to 255 (same on the zero end). When the inverse matrix is applied, the value will return to a lower value than it started out with. <br>
<br>
In my app, this will lead to the colours not being right. However, in my app, sometimes most of the colours are ok, but the places that are really quite bright, like the cheeks of Dr. Kaii, become splotchy in certain cases. If I then load that GUI combo into the game, the game won't have that splotchiness. <br>
<br>
Weirdly too, sometimes the game will be fine with it, sometimes not. Also, some profiles don't match what the game does to their avatars at all. So basically, I'm on the right lines, but not doing it quite right.<br>
<br>
Confounding this further is that some matrices don't have an inverse (the determinant is zero), so my program just exits the sub at that point, but Frontier's code still does something. So clearly they aren't just applying the inverse matrix.<br>
<br>
So yeah, I have pmed Matt, I have even opened a support ticket. They are very busy so I doubt I will get a resolution to this, so I am opening it to the community, especially the math boffins and the digital color experts. <br>
<br>
There is a commented out part of my code that deals with the inverse matrix directly (I did that, foolishly, to try it without the information loss, but of course that leads to perfect avatars 100% of the time, but I've kept it as it might come in useful for whatever weird process Frontier are using). You can either explain to me what you think they are doing and I will happily write the code myself to test, or you can use the source below to try it out yourself. If you get something workable, share it and I will reintegrate with EDProfiler and the community will rejoice <img src="https://forums-cdn.frontier.co.uk/images/smilies-frontier/smile.png" border="0" alt="" title="Smile" smilieid="70" class="inlineimg"><br>
<br>
Credit will be given of course. <br>
<br>
<br>
<a href="https://goo.gl/AtcyBS">Source Code.</a><br>
*Don't forget to add the EDProfiler folder to "My Documents" for the built-in profiles
