Since I don’t completely understand the bug yet, I’m just working on what I can. I put your case down to version differences. I’m basically just doing the standard debugging thing – eliminate possibilities. ![]() in GIMP) often may work out to no transformation at all. But stripping the metadata also should guarantee an image is imported as plain sRGB, which (eg. Well, that is exactly the case I was thinking of. Stripping the metadata only worsens the situation if proper management exists, unless the metadata is incorrect in the first place 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. So I’m still relatively clueless, but at least there is enough evidence in this thread to file a bug If by ‘uniform’ you mean ‘doesn’t occur on all pictures’, I agree. However, examining the SVG generated by Inkscape does not reveal any color management information. Export ignores this CM info (not implemented yet?) and so renders correctly. Theory: Correct colors are assigned to vectors, then the wrong color management info is assigned to them. Bug does not affect quantization (otherwise, export would use wrong colors). Bug is triggered by some particular aspect of the pixel data itself. Then I imported into Inkscape and traced this file.Ĭonclusion: Color management data on input image is not the cause. gamma, ICC profile) that could have been influencing things. This should remove any color management information (eg. Going on that theory, I also took the time to strip the PNG you provided ( optipng -strip all 1ebc2a5b146dd249142dd686577b65581b9b7afd.png). Like afre, I suspect that this may be related to color management.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |