| | <<<Back 1 day (to 2020/01/08) | Fwd 1 day (to 2020/01/10)>>> | 20200109 |
| sebras | ator: how did you come up with the patch though? | 06:23.58 |
| | it can't have been guesswork, can it?! :) | 06:24.25 |
| | ator: or perhaps this is a nice way of telling me: it took me ages to understand myself, and I don't have the willpower to explain it to you, don't bother trying to understand it. ;) | 06:25.20 |
| | ator: for "gl: Add -T option to print a script to replicate the user actions." | 09:29.38 |
| | ator: for "gl: Add -T option to print a script to replicate the user actions." | 09:29.49 |
| | ator: how do you feel about sebras/print-quads ? seems like it was missing,and could be used by the tracing code. | 09:32.09 |
| | ator: oh, so the trace file is inteded to be parsed by mutool replay depending on mujs to redo the actions? | 09:35.27 |
| | it looks like js code somewhat. | 09:36.37 |
| | assessing whether this commit covers all events that ought to be traced is difficult. I'm trusting that we can hash that out in the future. | 09:38.40 |
| | hence LGTM "gl: Add -T option to print a script to replicate the user actions." | 09:38.49 |
| ator | sebras: yes, the -T option prints a script that when run through 'mutool run' should replicate the user's actions | 11:21.55 |
| | sebras: the %Q patch prints with commas, %M, %R, and %P print without commas | 11:23.01 |
| mupdflover | Hey guy. I think i have an interesting case here. Probably no bug or something, but weird.... Maybe someone is interested to take look.... | 13:04.26 |
| | Regarding this PDF: | 13:04.35 |
| | https://ops42.ms-visucom.de/temp/demo/out.pdf | 13:04.37 |
| | If you view it with Google Chrome, you will see grey fragments around all occuring transparencies. On left inside the circle, on the right around those figures. | 13:06.03 |
| | Viewing this PDF with Adobe Reader will reveal the same. But only with default Config. | 13:06.32 |
| kens | That's likely to be a problem with Chrome, or more specifically pdf.js which does a terrible job with transparency | 13:06.46 |
| | Looking at the file with Acrobat X I see *some* of the images on the right have dark borders, at some resolutions | 13:07.31 |
| | On the left side I don't see any borders | 13:07.50 |
| | I imagine this depends on the exact placement of 2 images, and the rendering rules. Sometimes a pixel is overwritten by the image, and sometimes it isn't. | 13:08.59 |
| mupdflover | Sorry, i was disconnected. | 13:09.16 |
| | If you disable Image Antialising within the Adobe Readers Settings, the fragments will disappear. | 13:09.20 |
| kens | I see the same result with MuPDF as I zoom in and out | 13:09.30 |
| mupdflover | The PDF just contains two things: a perfectly clear PNG over a yellow background to make the effect clear. | 13:10.01 |
| | Here is the same png used inside the PDF embedded as an HTML: | 13:10.39 |
| | https://ops42.ms-visucom.de/temp/demo/ | 13:10.40 |
| kens | Not for me. On Acrobat X Pro turning off anti-aliasing makes no difference | 13:10.41 |
| | It can't be a PNG as such, because PDF doesn't support PNG | 13:10.56 |
| | It will have been turned into something else | 13:11.02 |
| | Note that MuPDF does anti-aliasing | 13:11.26 |
| | There may or may not be a way to turn it off, there didn't use to be in the past, but I can't recall if that changed (I am not a MuPDF expert) | 13:12.06 |
| mupdflover | OK. That might be. The PDF was built with PDFLib. | 13:12.18 |
| | I know. If i disable Antialising within mutool draw, the PNG looks terrible, but the fragments still remain. In my current Adobe Reader DC, i can disable the effect with unsetting Antialise Images. | 13:14.33 |
| kens | The tcontent starts by drawing a large rexctangle, 100% red and green, then there's an amepty stream. Then there's an image with a softmask | 13:14.34 |
| | Its 'smooth images' in Acrobat Pro X which does make the effect disappear. I'm pretty certain its down to the underlying mask shining through the transparency | 13:15.10 |
| | You'd have to get one of the MuPDF developers to check it, but the fact that Acrobat behaves the same suggests that its the same problem | 13:16.11 |
| | Basically its a known problem with anti-aliasing and transparency, I'm not certain there's a good answer | 13:17.16 |
| mupdflover | Hmm... I have seen a lot cases till today, but this one is new to me. I dont see any problem with the PNG inside Photoshop. I can even resave it for web - same effect. | 13:18.47 |
| kens | Its (probably) because there isn't a single image in the PDF, there are two | 13:19.14 |
| | One is the actual image, the other is the soft mask. In effect its the PNG transparency layer but instead of being a channel in a single file, its tow discrete objects | 13:19.50 |
| | Because that's how PDF transparency works | 13:20.08 |
| ator | mupdflover: the page has 1) a yellow background, 2) a RGB image with 3) a soft mask | 13:20.35 |
| | the 'borders' are a side effect of antialiasing and alpha compositing | 13:22.11 |
| mupdflover | Ah, i see. Just used mutool extract and now i see both files. Tough i dont have any clue why this happens here. I saw much more complicated scenarios without such effects. | 13:22.56 |
| ator | mupdflover: it's a well known side-effect of linear interpolation and alpha compositing when the alpha and color are *not* premultiplied | 13:24.04 |
| | which doesn't happen in PDF because the soft mask and the color image are separate images rendered in different passes | 13:24.30 |
| | the 'border' in the 'color' image goes from black to white and ends up with a gray line | 13:25.33 |
| | then the border in the 'alpha' image also goes from black to white and is gray | 13:25.44 |
| | but the way the math works out, this ends up looking darker than it should | 13:26.00 |
| | it may be an issue with mupdf's compositing of soft masks, where we miss a potential alpha premultiplication step. | 13:26.39 |
| kens | Acrobat does the same | 13:26.49 |
| ator | it's hard to say without digging deep into the code, it's been a long time since I messed with this | 13:26.50 |
| mupdflover | Ah, ok. Fun fact there is, that the effect does not occur, when the PNG is downscaled to a (not predictable) size before. So some rounding error does only have effect at a specific point? I have no idea ;-) | 13:27.19 |
| ator | kens: I'm not surprised. it's a pretty common problem with transparency masking and interpolation. | 13:27.37 |
| | you can get the same problems just resizing a transparent image in photoshop or gimp | 13:27.54 |
| kens | yeah, but you are explaining it much better than I was :-) | 13:27.56 |
| | Scaling the image (and zooming in and out has this effect) changes the exacct pixel placement so you get different effects | 13:28.29 |
| | Some borders appear, some disappear, etc. | 13:28.37 |
| ator | if you know the keywords to look for, there are hundreds of stackoverflow questions asking about the same issue on the 3d programming forums | 13:29.04 |
| | textures get "black borders" etc | 13:29.08 |
| kens | Basically its just how the maths works out | 13:29.09 |
| mupdflover | For me it is new case ;-) Is there some way so get around this? Would converting to a tif help? | 13:29.14 |
| kens | Using a different image format won't help, no | 13:29.35 |
| ator | mupdflover: there's not really anything you can do | 13:29.36 |
| | avoid hard edges like that | 13:29.48 |
| | should reduce the problem | 13:29.52 |
| kens | You can turn the image+transparency into an image with the transparency rendered into it, not much else will help | 13:30.07 |
| ator | or flatten it so there's no transparency involved | 13:30.28 |
| mupdflover | The circle on the left has no hard egdes. Its soft ? | 13:30.33 |
| kens | its got jpeg artefacts | 13:30.57 |
| | so its more or less soft | 13:31.02 |
| mupdflover | I dont get "you can turn the image+transparency into an image with the transparency rendered into it"? | 13:31.07 |
| kens | What tor said, flatten the transparency | 13:31.17 |
| mupdflover | But i would lose the transparency then? | 13:31.39 |
| kens | I'm finding it hard to explain this, I must be tired. | 13:32.17 |
| | Yes the final image would have no transparency | 13:32.27 |
| mupdflover | I can not know before whats is under the transparency :-( so i can do nothing? | 13:32.30 |
| kens | Becuase you would render the PNG and teh backdrop to another image format and the rendering woudl include the transparent effect | 13:32.50 |
| | If you don't know the backdrop, then no there's nothing you can do | 13:33.02 |
| | as Tor said, avoid hard edges (the white rectangels have hard edges) | 13:33.18 |
| | You can stop using anti-aliasing as well of course | 13:34.11 |
| mupdflover | Okay. Using "mutool draw -A 0" makes the PNG look terrible, but the fragments stay. | 13:35.32 |
| ator | mupdflover: so what actually happens here is because of downscaling the image | 13:36.04 |
| | when scaling the image down to fit the screen, we resample it turning the hard edges into gray | 13:36.28 |
| | but since the mask and the alpha are not in the same image, they get resampled separately | 13:37.14 |
| | and thus the alpha premultiplication doesn't happen, which is required to not get these hard edges | 13:38.07 |
| | you can turn resampling off for upscaling (by adding /Interpolate false to the image dictionary) | 13:38.31 |
| | but that only affects upscaling, not downscaling | 13:38.49 |
| mupdflover | Okay, i understand. I think so at least ;-) Was just suprised to see that effect the first time. So one ugly solution could be to try to refactor the PNG by trial and error until the effect is gone? | 13:39.54 |
| ator | if you turn off interpolation and render at a size where the image is not reduced in size compared to the original image, you should be asfe from these artefacts | 13:39.58 |
| mupdflover | OK. But that would be an perfomance penalty :-( | 13:40.42 |
| ator | mupdflover: actually, come to think of it, there is as olution | 13:42.34 |
| | if you look at the PNG image, when it has 0 alpha (completely transparent) it still has a color | 13:42.52 |
| | look at the extracted images, img-0007.png is the mask | 13:43.16 |
| | img-0011.png is the color | 13:43.24 |
| | see how the transparent bits (the black areas in 0007) are also black in the color image 0011 | 13:43.54 |
| | that black color is what's bleeding through to your transparent edges | 13:44.11 |
| | if you make those areas white instead, you wouldn't see the black borders | 13:44.22 |
| | https://answers.unity.com/questions/10302/messy-alpha-problem-white-around-edges.html | 13:45.13 |
| | I take back my ramblings about premultiplied alpha, that's not the real issue here | 13:46.00 |
| mupdflover | Sounds interesting! But: the 1. PNG itself was generated from PDF before with mutool draw. 2. Even if resave that PNG with Photoshop "save for web", the effect remains? | 13:46.07 |
| ator | the issue is that you're getting exactly what you're asking for :) | 13:46.10 |
| mupdflover | I dont see anything dirty within Photoshop? | 13:47.04 |
| ator | mupdflover: a *lot* of PNG tools zero (black out) the color for pixels that are completely transparent | 13:47.10 |
| | can you look at the color without alpha channel? | 13:47.47 |
| | mutool draw leaves transparent pixels black colored, I think. that could be easily fixed. | 13:48.36 |
| | ah, no, it can't because we always use premultiplied alpha (and anything * zero == zero so the color information is lost) | 13:51.12 |
| mupdflover | Just confirmed "see how the transparent bits (the black areas in 0007) are also black in the color image 0011". I understand more and more.... | 13:52.28 |
| | So i have to stick with "refactor the source until the effect disappears"? Why can Adobe Reader avoid the effect by a setting? Viewing the PDF with Firefox also does not seem have the effect? | 13:54.31 |
| ator | if you always use nearest neighbor sampling, there will be no rescaling artefacts | 13:55.12 |
| | mupdf doesn't have an option to turn off resampling when scaling images down in size | 13:55.28 |
| | the PDF format has an option to turn off resampling when scaling images up (and only up) | 13:55.50 |
| | in order to let pixelish blocky images remain pixely | 13:56.12 |
| mupdflover | So "mupdf doesn't have an option to turn off resampling when scaling images down in size" happens, when the option in Adobe Reader is unchecked? | 14:00.50 |
| ator | I expect that turning off AA in adobe reader also turns off image resampling | 14:01.39 |
| kens | There's only one control called 'smooth images' not clear exactly how it operates | 14:02.12 |
| | Coul dbe AA or interpolation, or both | 14:02.30 |
| | FWIW Ghostscritp does not show the edges, but with -dDOINTERPOLATE(which forces interpolation on) it does | 14:03.22 |
| mupdflover | Confirmed with the PDF i showed you as link. I see fragments, but only very(!) slightly. This PDF has proportional other bounds than one i tried it with. This should be another argument for a math/intorpolation case. | 14:08.55 |
| | In my fail case the image and pdf was set to 150/150. The linked one is 1500/1500. | 14:10.16 |
| | So trial & error to the rescue then ;-) | 14:10.44 |
| | So guy. At first, thank you for clearing some things up to me! But i am still not completely there. Scaling sperate Images (mask and actual image content) may lead to differences. OK. But for this example: if i put the mask above the image content as two layers inside Photoshop, i still dont get the issue for the hard egdes. Mask and image content | 15:34.12 |
| | have the same dimensions and the "hard edges" are exactly on the same position. Where is the math / rounding / scaling issue here?! | 15:34.13 |
| ator | it's not a rounding/precision issue. it's that when rescaling the image to a smaller size, the black color in the fully transparent part bleeds into the non-transparent part | 15:37.56 |
| mupdflover | Short after my writing, i think i got it finally. As the "inside photoshop visible" hard mask gets scaled, there is no fixed black/white anymore, but something in between, which results in partial rendering of the actual image content? | 15:38.19 |
| ator | the border you see comes from mixing a "fully transparent black" pixel with a "fully opaque white pixel" turning it into a "semitransparent gray pixel" | 15:38.29 |
| | I think what you just said is correct :) | 15:39.26 |
| mupdflover | Yeah. Thank you, sir! Still struggeling with the fact seeing this the first time for so many years ;-) | 15:39.48 |
| ator | now if you make the fully transparent part white (or match the surrounding opaque part's color) then you would get a semi-transparent white pixel which is what you were hopefully expecting to see | 15:40.41 |
| mupdflover | I understand. In fact i have no control for the source. 1. A (semi) transparent PDF i cant know gets uploaded and rendered as PNG. Afterwards the PNG will be placed inside a new PDF which size as well as the placement of the PNG i also do not know. So the only chance would be to scale the png before placement inside to PDF to the actual pixel | 15:44.26 |
| | values to avoid scaling. Possible, but a performance hit. | 15:44.27 |
| ator | you could postprocess the PNG to fill any fully transparent pixels with the neighboring color | 15:45.14 |
| | or render twice -- once without transparency, once with, and take the color from one and alpha from the other | 15:45.36 |
| mupdflover | Which i also cant know before the PDF gets build ;-) | 15:46.00 |
| ator | you said you used mutool draw to render the PDF to a PNG? | 15:46.18 |
| | render once with and once without transparency, then mix and match the results | 15:46.35 |
| mupdflover | Yes. 1. PDF to PNG via mutool draw. 2. 2 Days later: the png will be placed inside a new Document (which contain anything) at first rendered as PDF. Afterwards a screen preview will be built as PNG. Again with mutool draw. | 15:48.13 |
| ator | mutool draw -o color.png -c rgb input.pdf | 15:48.23 |
| | mutool draw -o alpha.png -c rgba input.pdf | 15:48.31 |
| | convert alpha.png -alpha extract alpha-mask.png | 15:48.53 |
| | and then some similar command to combine the color.png and alpha-mask.png | 15:49.39 |
| | anyway, gotta go. good luck! | 15:50.31 |
| mupdflover | I dont get it. But thank you very very much and have a nice day! | 15:51.26 |
| | What difference should it make to let "mutool draw" at first render the mask and the image seperately and let ImageMagick combine them afterwards instead of letting "mutool draw" doing its job on its own? | 15:54.52 |
| | <<<Back 1 day (to 2020/01/08) | Forward 1 day (to 2020/01/10)>>> | |
Log of #mupdf at irc.freenode.net.