There is a claim that colour space conversions "kills a phone". That's the clickbait. It is at the youtuber to support their claims, in a concise and reproducible way. It is not at us to prove them wrong, which is basically impossible because lack of reproducibility (buzzwords). You know, there is the concept of "not even wrong" that disables concise answers because there are none to the claims.

I could join the guesswork with speculating how an overflow, an underflow, an nan or an inf or div by 0 could crash a program, but to what avail ? All the information necessary is missing in the example. I think that (if that's an uint8_t where the final value ends in) it simply wraps around to 0 because that is how these work. Mind you, that is not an error ! An error would be to use the 0 unchecked for division.

ThinKing_2005 Also, maybe GLES2 and GLES3 have something to do with this.

Well, if there is a concrete issue, let's get behind it and solve it. What do those apis have to do with what ? What error did actually happened, and is it reproducible ? Because it not, there won't possibly be a satisfying answer.

      Pixophir I see, so you're saying the problem itself is not even real, to begin with. Although, I disagree because of the following reasons:
      1- Lots of people seem to agree in the comment section. I'm not saying they must be all truthful, but when the number is that high, well I just doubt that the problem is not even there.
      2- You talked about reproducibility, and the video actually talked about how to reproduce the problem; simply find the pic and set it up as wallpaper of an old Android phone with no updates to the system (the guy who took that pic is linked in the description of the video, and I myself searched and found the pic).
      3- The guy simply saw a problem spread on the internet, and tried to solve it... with the help of a team, all linked also in description,
      4- The error is rare, and he himself (and his team) couldn't replicate it with other colors.
      5- The guy has a good record of credibility.

      So if you really can't believe what he's saying, despite the points mentioned above, go ahead and try it. Did I try it myself? No, because I'm not ready to lose my data over something as silly.

      Finally, I just wanna say, what's the point of all this? I'm simply suggesting an answer that COULD work, but never said it will for sure. The guy can simply try it and then tell if it works or not. You suddenly came in saying that the video I shared has 0 info (wrong) and called a scam.. because the error happening in the first place is illogical. What about the many people that experienced it? And, even if around 1 million people who liked the video are all either blind followers or bots, and the video is proven wrong (which I still don't agree with), does it make a difference anyway? I already stated that I don't think the same thing is happening with nb_dot, just that MAYBE the problem is related to color space since Photoshop uses a wider.

      All in all, with all due respect, I simply don't see how you're correct that the video is a scam or clickbait, nor do I see how is that in any way helpful to the guy nb_dot having a problem. Is any of this going to really solve it? Just remember the actual purpose of this discussion, to solve a problem. If you have no more NEW points or experiences to share, then I humbly ask you not to continue this discussion, because I simply don't see where it will get any of us.

      Thanks for reading it all!

            Just because it's not technically bricked doesn't mean a misconfigured device isn't as good as bricked to a non-technical user. Something-something sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clark, I think.

            Hi, wow, so let's keep calm and see why the problem in the video (if it exists) has nothing to do with the OP asking which formats to use for import and why there are jaggy and white edges. Which has largely been solved, I take it ? Any way, rough edges probably have to do with the (lack of) resolution.

            A screenshot and the offending image for download would make it easier to give a qualified answer, if it is the source image or somewhere in Godot. As said already, there should not be problems with PNGs.

            To the video: the guy shows a linear expression of ax + by + c*z with x,y,z from 0.0 to 1.0 such that their sum is 1.0 and a,b,c each from 0 to 255. All values floating point (conversion else no calculation on a computer). That alone is a hint to a programmer that checks must be made, simplistically said (irl it maybe more complex) clamp the sum of x,y,z to 0.0..1.0, check ranges of a,b,c if they are 0..255, or simply check if the expression results in 0..255 and clamp/expand/compress if necessary. Specifically when things come from an external source. Not doing this is careless and inviting disaster, likely to get garbage values, maybe from precision problems alone. Still, these should not make a phone unusable, if they do, there is really bad software involved and possibly more serious problems looming than just a blocked phone (speculation mine).

            Anyway, when solving the expression and the outcome is > 255.0, then there is not yet an error (as claimed by the video guy). That can happen and must be accounted for as said, in any way that leads to a safe conversion to the narrower range of 0..255. Or, if a repair would result in too much distortion or false colours or whatnot, an error must be raised. This is really basic stuff for a coder, and should not break any functionality. And that's (among other things) why I said the video is clickbait and does not really explain anything.

            This is all only valid if we actually accept the video to be genuine, of which I have expressed my doubts 😜

            Edit: the same arguments are valid for the generation of the image by some software, of course.

              I didn't watch the video, but I have heard of problems like this before. It really has nothing to do with color spaces or image formats. It's just a basic rookie mistake of programming. You always need to check for edge cases, especially when you accept user generated content. So check the bounds, is the value below zero, exactly zero, exactly the maximum, greater than the maximum you are expecting? What happens if the file is blank, or in the incorrect format (for example, loading a text file when you expect an image). Is the format malformed (for example, if checking a C-style character array, what happens is the last character is not null-terminated)? Are you sure that the size of the file or array is the actual size? Things like this, this is what they teach you in college for Computer Science. So my guess is that whoever programmed that image loader on Android is just a noob.

                Megalomaniak changed the title to Dangerous Colorspaces? discussion .

                Pixophir I just wanna say, considering the problem presented in the video is legit, your whole argument revolves around the fact that such an error happening is not possible because it's too simple for professional coders. But I hate to break it to you; people make mistakes. As cybereality mentioned, it's not ONLY color spaces, but there are many other things that need to be checked for. It's like you're saying people who program video games are professionals, it's impossible to have glitches in games, hence any video game glitch video is clickbait. Except, you probably experienced game glitches before, so you can relate to that better.

                Anyway, the correct answer is probably as what Kojack explained, it just seems more logical.

                      I felt it was too much and too off topic so I split the posts out.

                      If the luminance formula given in the video is what android uses, and it's doing a ceiling of each channel like so:

                      float lum = ceil(0.2126 * r) + ceil(0.7152 * g) + ceil(0.0722 * b);

                      Then there are 76 input colours that would generate a luminance over 255.

                      My guess is they must be using luminance as the index into a look up table when converting Prophoto RGB (also called ROMM RGB) to sRGB. Since the luminance is 256 or greater for 76 colours, those cause the conversion code to read past the end of the table, causing a Java error (ArrayIndexOutOfBoundsException by the sound of it).

                      So basically they did some float to int maths, didn't realise that in edge cases it gives a higher value than they wanted, then got caught by Java's bounds checking.

                      Something slightly related I've seen hit game engines is calculating angles between vectors.
                      The usual formula is the angle = acos(dot(a,b)) where a and b are normalised vectors.
                      Nice and simple. acos only accepts values between -1 and 1. The dot product of 2 normalised vectors will (theoretically) be between -1 and 1.
                      EXCEPT... in the real world due to floating point issues a normalised vector may be a tiny bit longer or tiny bit shorter than truly normalised. Dot product them and you get a value that might be something like 1.00001. Give that to the system acos function and the result is an indefinite NAN (which will mess up everything it touches).

                      I've seen this happen multiple times to people using the C# port of the Ogre3D graphics engine. The C++ version had safety wrappers for acos and asin to protect against bad values, so that worked fine. But the C# port just used the system acos and asin, which freak out at bad values.

                        Kojack ArrayIndexOutOfBoundsException

                        tststs :-)

                        Ok, that's much closer to useful detail. I don't say this doesn't happen to me (it does as documented in here by the verdict of valgrind), but I check and try to eliminate such errors. In productive software it should not, and if it chrashes the program it should not hang the machine.

                        Btw., I would expect the kernel to signal a segfault in such a case and show the door to the program, is the Android Kernel stripped of such features ?

                          A seg fault is caused by the hardware detecting you are trying to access memory you don't own.
                          In the case of reading past the end of an array, that wouldn't cause a seg fault if the next bytes of memory after the array are also owned by the same program.

                          Well, that's a bit more complicated, there's hard- and software involved, MMU and the kernel managing process memory. Writing to process owned memory can also cause a segmentation fault, if the respective memory is read only or the requested memory not mapped to the program (e.g. when writing out of bounds).

                          But I am not an expert, and we're deep in undefined behaviour, so predictions are moot anyway, I retract the question whether Android is less memory safe than a desktop Linux.

                          So, to conclude, this has nothing to do with color or spaces. It is just a basic out of bounds value (could be buffer overflow, could be illegal array access, divide by zero or otherwise NaN, etc.) which basically means you are accessing protected regions of memory or generating undefined behavior, which could cause the app to crash (or worse, depending on what is in the unintended memory address). This can happen with any user generated content or input, which is not properly checked or sanitized. So a rookie mistake.