png image (with transparency) drawn over progressive jpg is blurry

[pedrobagatin]

I was having this issue: "no SOI" error when loading some PNGs, basically images are not shown properly (ex: if it is an image showing text, like title, which has alpha channel, transparency), it becomes blurry. So first updated stb_image version to 2.27, therefore got rid out of SOI error message, but problem still happening. One way to fix it was by saving image using gimp (png to png conversion). I noticed it converts from adobeRGB -> sRGB when loading it in gimp, later also has some options for the conversion (compression rate, background color, transparency, etc) so I think it might be a good reason to fix the problem. Two other things I noticed which I don't know if they are problematic:

1. Background image is an opaque background from a progressive jpg image.
2. When loading this progressive jpg file I get "bad png sig" which is weird because it isn't a png but a jpg.

Conclusion: I could fix for images that I am responsible for using gimp, but some of them come from third-party provider which I can`t convert before hand, any ideas/suggestions how to fix for this case?

[nothings]

Unfortuntely, if you can't provide sample images, we can't do much. "It becomes blurry" could mean anything.

2. When loading this progressive jpg file I get "bad png sig" which is weird because it isn't a png but a jpg.

Does loading the progressive jpg return an error code? You shouldn't look at stbi_failure_reason unless the load returns an error, as it will contain spurious error strings as a side-effect of the loading process.

[pedrobagatin]

I investigated better the image using imagemagick and figured out the image I am seeing is without alpha component, I think problem might be in OpenGL, and png image from the third-party is adobe RGB, when I use gimp it converts automatically to sRGB which reduces the color spectrum I think, colors are a little dim.

In my code implementation, in stbi_load I get 3 for n_channel for jpg images and 4 for png. Is it okay to load both images using number of components as STBI_rgb_alpha or should I make some distinctions? Thanks for the help.

[nothings]

it's ok to use STBI_rgb_alpha for both, that is why it exists. you CAN force the image to a known fixed number of channels, or you can load it and preserve and handle an arbitrary number of channels. either is reasonable, depending on what you want to do.

[pedrobagatin]

Hi again, still working on the problem, but found out some things.
1st) Images use IEC61966-2.1 which is a non-free colour profile according to google/cadvisor#915 (from another project)
2nd) Transparency has a range of values on the picture making it in some places to act as a gradient but even for small values of alpha higher than 0 it gets totally opaque (there isn`t translucid, semi-transparent effect)
3rd) I think program used to generate these pictures was photoshop, do you treat this type of IEC61966-2.1 in your library or should I change metadata or convert image before using them?

Thanks again for the help

Edit: found some images examples, it's near the word border that problems happens
To check the images, please use GIMP or another image editor.

.

[nothings]

stb_image ignores all color profiles; if the file has 8-bit input and stb_image is producing 8-bit output, there isn't enough precision to do any color transformations. but normally alpha is not affected by color profiles.

[pedrobagatin]

Ok, but how about the images? I am not sure where the problem might be.. raw images don't work, but if I use GIMP and export them it works.. so weird.

[nothings]

i don't have enough information to guess, other than to point out that your images display as all white in firefox so you can't actually see them, so

[pedrobagatin]

It is working after some operations in alpha channel, got some old code of my project multiplying alpha by each pixel component and adding 0x80, then doing some shift right operations as well, really doesn't make sense. Weird is that if I use another image type, alpha works without needing all those weird operations. If, in the future I figure out what operation is doing will try to explain.