-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gdImageRotateInterpolated() converts the source image to truecolor #320
Comments
All interpolation converts to TC yes. It makes thing too complicated with palette while massively reducing the quality. |
This is not about the output (or the internal calculation), but rather the fact that the source image is converted to true-color. This might have better been solved by only supporting true-color images in the first place (and failing for palette images), but we cannot change that anymore. However, we should document that this conversion is happening. |
oh, the original image is converted? sorry I misread. That should not happen. I will look into it. |
Lines 1882 to 1887 in 9af6d12
Solution would be simple: just create a copy of the src image before converting to palette. I'm not sure whether it's worth it. Users can do that themselves if they need to retain the source image (often there is no need to). |
It is needed to be converted anyway. The fix is: At this stage I would like to go with the "fix" rather than making it non obvious. If the src changes, the parameter should be ** at the very least (to make it clear and not const *). |
That's fine for me as well. :) |
PR done, please check :) |
Fix #320, should not convert the source to palette
If a palette image is passed to gdImageRotateInterpolated() it is converted to truecolor. That is at the very least unexpected, because gdImageRotateInterpolated() is supposed to return a modified result, but not to change the source image.
Test Program
Expected Output
Actual Output
The text was updated successfully, but these errors were encountered: