Furry stuff, oekaki stuff, and other stuff.
You are not logged in.
Hi,
No changes are saved to retouch, I could help?
thanks
Alea wrote:
Hi,
No changes are saved to retouch, I could help?
thanks
It only affects animations
Sometimes also to tweak the image just does not come out before, if there is a previous retouching.
thanks
This bug appeared in ShiPainter a few years ago when a new version of Java was released.
I've been trying to fix it for a long time, but for many technical reasons I've been unable to do so. Unfortunately, I don't have the source code to ShiPainter, and it won't decompile, so I don't think there's anything I can do to fix animations.
Offline
Thanks for the clarification.
Remember from that version is compatible?
Or if it works with any version of Java on Linux OpenSDK?
There is a problem also in retouching in ShiPainter? That sometimes good and sometimes not load.
thank you very much
I believe Java 5 is the last version that had no issues, so you're looking at a version that's about 7 years old. That's not recommended. I don't recall exactly when the bug appeared in Java 6, so maybe there's an early release of 6 that works.
Testing the animation bug is difficult, since it only seems to appear randomly with fairly long animations. The corruption may appear at any point in the animiation file, but whether an animation will be broken or not is unpredictable.
From what I understand, the problem is that the animation data cannot be uncompressed because the compression header length is wrong. This happens when the animation is being saved. To allow animations to be streamed, the data is chopped into 64K chunks which are compressed individually. For some reason, once in a while, a 64K chunk isn't compressed correctly, and that breaks the animation from that point onward.
I've decompiled portions of ShiPainter to investigate, and I'm guessing it's a type casting issue when adding the compression header length to the animation output buffer. It's possible the applet is making assumptions about how the byte order is interpreted by Java, and this may result in an invalid number in certain cases. The Shi applets are pretty badly written (at least according to my brother-in-law, who is a Java expert), and type casting issues exist in many places. As I mentioned before, I can only investigate the cause of the problem, not fix it. I don't have the complete ShiPainter source code, and the applet doesn't fully decompile. Shi-Chan, the original author of the applets seems to have disappeared from the Internet. I have no idea how to contact him, and in the past he never replied to any of my e-mails.
The only workaround I know is the load the picture data directly, rather than the animation when retouching. If you try to open a picture into an applet and the picture is broken/incomplete, scroll to the bottom of the page and click the link at the bottom that will try to retouch the picture using the original image. The animation will still be broken. As far as I know, there is no way to fix a broken animation (I've tried a few times, to no avail).
Interestingly, PaintBBS uses the same technique to save animation data, and it does not appear to have the same issue as ShiPainter. I'm not a Java programmer, so I haven't been able to figure it out.
Offline
Thank you very much for the explanation as complete
Know if animations besides also passes retouching images?
Since costs will randomly pick the first retouch
Alea wrote:
Thank you very much for the explanation as complete
Know if animations besides also passes retouching images?
Since costs will randomly pick the first retouch
Sorry, First retouch works, second randomly