No, I exported a PNG directly from Inkscape, The GIMP and sxiv screenshots were mainly to ascertain that color management wasn’t causing the variation in color.
I’ll re-trace and check the saving thing.
EDIT:
Results are as follows:
Saving the svg and re-loading into Inkscape makes no difference (still shown yellow)
Importing SVG into GIMP gives a similar result as exporting from Inkscape (ie. correct colors)
Importing the exported PNG back into Inkscape shows correct colors.
Like afre, I suspect that this may be related to color management.
Going on that theory, I also took the time to strip the PNG you provided (optipng -strip all 1ebc2a5b146dd249142dd686577b65581b9b7afd.png). This should remove any color management information (eg. gamma, ICC profile) that could have been influencing things.
Then I imported into Inkscape and traced this file.
Result: Still yellow!
Conclusion: Color management data on input image is not the cause. Bug is triggered by some particular aspect of the pixel data itself. Bug does not affect quantization (otherwise, export would use wrong colors).
Theory: Correct colors are assigned to vectors, then the wrong color management info is assigned to them. Export ignores this CM info (not implemented yet?) and so renders correctly.
However, examining the SVG generated by Inkscape does not reveal any color management information. So I’m still relatively clueless, but at least there is enough evidence in this thread to file a bug report.
@afre: If by ‘uniform’ you mean ‘doesn’t occur on all pictures’, I agree.
Last I checked PoTrace didn’t have any multitrace support; anyone who wants to implement it needs to at minimum generate an indexed image, sort its palette by perceptual brightness, and pretend that index == grey value as they repeatedly feed the same image into potrace, varying the --threshold value.
I haven’t tried the first point but for me the PNG still exhibited incorrect colors.
Color Issues
I rarely use or follow the development of Inkscape anymore, but my impression is that it is fairly color management agnostic. There are a few controls in the GUI but they don’t do anything yet, unless I missed a new development. Stripping the metadata only worsens the situation if proper management exists, unless the metadata is incorrect in the first place. Moreover, PNG color profiling is still uncommon.
I wasn’t referring to the assigning or recognition of metadata but how Inkscape manipulates and handles (“manages”) the actual data. Anyway, color is a difficult nut to crack. @Elle’s website may help clarify some issues at play, though she focuses on raster processing.
Lastly, feel free to file a bug report, but I feel that we don’t have enough info to warrant proper attention. I suggest you bring this up in places where Inkscape developers are carrying out active conversation. As I don’t see an Inkscape Category on this forum, this might not be the best place to get results
Well, that is exactly the case I was thinking of. But stripping the metadata also should guarantee an image is imported as plain sRGB, which (eg. in GIMP) often may work out to no transformation at all.
I’m basically just doing the standard debugging thing – eliminate possibilities.
I put your case down to version differences. Since I don’t completely understand the bug yet, I’m just working on what I can.
… That’s not different in a practical sense. If you aren’t using available CMS metadata to manage the image, then there is no guarantee that your pixelwise operations on the image will make any sense.
In any case, my tests were designed to eliminate the possibility that Inkscape was correctly color-managing the image based on wrongly set colorspace information, which AFAICS they did. It’s pretty likely IMO that color management is unrelated to this bug (but at the same time, it’s the only guess I have at what could cause it.)
In other words, I am fairly confident that my theory is wrong. But it’s still the only theory I have so far
Well, that makes two of us
I’ve added a comment to this existing bug report that hopefully may prompt some feedback on how to properly track down the cause of this bug.
The only idea I have for that currently is to find another image that causes similar discoloration.
