| | <<<Back 1 day (to 2018/09/12) | 20180913 |
| sebras | delrier: can you try with this patch? http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=5c276e31c | 11:25.15 |
| | delrier: it fixes the issues I have seen on my own files, but since I can't reproduce your issue I can't test it. | 11:25.32 |
| | tor8: sebras/master has no less than five commits, hopefully fixing three bugs (one would be delrier's mentioned above) and two oss-fuzz issues. | 12:53.51 |
| | oh and it clusters well with progressions, see my latest bmpcmp. | 13:06.14 |
| tor8 | sebras: p0_05.j2k looks similar to the 'B&W problem' reported by delrier | 13:09.34 |
| | sebras: did Robin_Watts look at "Bug 699769: Fix bugs in upsampling code for JPX images."? | 13:10.24 |
| Robin_Watts | I did not. | 13:10.35 |
| tor8 | sebras: I see no problems with sebras/master ... though I don't claim to understand the upsampling commit | 13:12.53 |
| sebras | tor8: yes, I did notice the similarities. | 13:13.36 |
| | tor8: the upsampling commit originally wrote outside the pixmap samples. | 13:13.48 |
| | tor8: the reason being that l2subfactor() used a too large upscaling factor. | 13:14.19 |
| | and no out of bounds checks when that factor was being used. | 13:14.33 |
| | however, just adding these checks does not resolve the issue. | 13:14.45 |
| | because the factor will be used for all instances where samples are upscaled, not just the ones close to the boundaries of the image. | 13:15.16 |
| | additionally I did find that openjpeg does provide a upscaling factor. | 13:15.32 |
| | not sure why I didn't get around to using that last time around. :) | 13:15.45 |
| tor8 | is the comp->dx and dy how much to upsample? | 13:16.28 |
| sebras | yes. | 13:16.51 |
| | also x0/y0 and x1/y1 for the jpx image defines wher the image is located according to the reference grid while x0/y0 for a component tells you where the component samples should be placed in relation to the reference grid. | 13:17.53 |
| tor8 | and you have no special case for when they are 1 | 13:17.54 |
| sebras | now.. only a part of the reference grid is actually output as an image... don't ask why. :) | 13:18.09 |
| tor8 | sebras: tiles. | 13:18.23 |
| | jpeg2000 images can be chunked up into big tiles | 13:18.46 |
| sebras | no, I just rely on the same code if there is no subsampling. | 13:18.52 |
| tor8 | I guess jpeg2000 is slow enough that it won't matter :) | 13:19.10 |
| | and branch predictors fast enough | 13:19.19 |
| | LGTM then | 13:19.22 |
| sebras | I tried to time if on my rather beefy machine, and I couldn't find any significant difference. the variations in rendering between different runs were bigger than the difference between the old and patched versions. | 13:20.06 |
| tor8 | yeah, I expect the difference to be immeasurable | 13:20.26 |
| sebras | at least now it renders more images correctly than it used to, and there are no out of bounds accesses. | 13:21.29 |
| | perhaps I should be checking whether the components fit within the image dimensions | 13:21.49 |
| | or if dx/dy are zero. | 13:21.58 |
| | maybe I should construct a sample file to see how openjpeg handles that. | 13:22.17 |
| | tor8: oh and yes, I did test with luratech too. | 13:34.53 |
| moolc | sebras: FWIW plenty of slow machines here (rpi3, ppc macmini, ps3) heck i don't think even my nain machine can be considered fast anymore :( | 13:43.51 |
| sebras | tor8: this fixes two open oss-fuzz bugs. of the ones remaining one is due to the bug in clang. another seems to be due to oss-fuzz limiting memory usage, while the remainder of them are due to bugs in openjpeg itself. I believe those can all be fixed by upgrading openjpeg. | 13:45.10 |
| | moolc: ok, let me know if you see any significantly degrading performance numbers. | 13:46.19 |
| | moolc: at least now it renders more j2ks correctly and doesn't crash. | 13:46.50 |
| moolc | sebras: oh, i don't test with those.. (not regularly anyhow).. once in a blue moon i just feel the need to check if things work on "exotic" hardware | 13:47.24 |
| delrier | sebras: if I clone the master repo will i get your patch? or should I clone "http://git.ghostscript.com/?p=user/sebras/mupdf.git" ? | 13:58.54 |
| sebras | delrier: if you clone the master repo now you will get my patch. | 13:59.45 |
| delrier | Also, I realized I might be making a misstake cloning master, should I rather clone the "1.13.0" tag for the most stable release? | 14:00.24 |
| | ok great :) | 14:00.26 |
| sebras | delrier: master is the one I'd like for you to test now. | 14:01.08 |
| delrier | I'm on it :) | 14:01.18 |
| sebras | thanks. | 14:01.22 |
| | I need to pop out for while, but I'll come back to read the logs. | 14:01.33 |
| delrier | sebras: I'm still getting red areas unfortunately | 14:20.48 |
| | (same pdf) | 14:20.59 |
| | I'll try the 1.13.0 tag and see if I'm getting the same issue | 14:21.11 |
| sebras | delrier: that's not good. you're probably going to see the same issue at 1.13.0 | 15:00.11 |
| | it is curious that the symptoms are identical though. | 15:00.32 |
| | Forward 1 day (to 2018/09/14)>>> | |
Log of #mupdf at irc.freenode.net.