| | <<<Back 1 day (to 2018/03/29) | 20180330 |
| kens | chrisl ping ? | 09:28.25 |
| Robin_Watts | Ass. | 10:28.29 |
| kens | Donkey ? | 10:28.39 |
| Robin_Watts | mvrhel_laptop pointed me a gen_ordered as a way of getting threshold screens. | 10:28.51 |
| kens | Yep | 10:28.57 |
| Robin_Watts | but I need cmyk, not just greyscale. | 10:28.58 |
| kens | Then you need 4 grayscale screens at different angles | 10:29.10 |
| Robin_Watts | How do I pick the angles? | 10:29.27 |
| kens | Doesn't gen_ordered let you choose ? | 10:29.37 |
| | I'm not familiar with the tool.... | 10:29.44 |
| Robin_Watts | 0, 22.5, 45, 67.5 ? | 10:29.50 |
| kens | That's one possible set | 10:29.57 |
| Robin_Watts | I can tell it what angle to use, but that presupposes that I have a clue which angles I want. | 10:30.12 |
| kens | If I had a memory I could remember... | 10:30.25 |
| | There are basically 2 sets that are in common use for CMYK, I just cant recall what they are | 10:30.41 |
| | 0 and 45 have to be two of them | 10:30.48 |
| | I think 15 and 'something' are another possible set | 10:30.59 |
| | OK so 0, 15, 45 and 75 | 10:31.22 |
| Robin_Watts | (K 45º, C 15º, M 75º, Y 0º) ... | 10:31.29 |
| | yeah, thanks. | 10:31.33 |
| kens | Yeah yellow goes at 0 because its the most objectionable angle, and yellow is the least commonly used ink | 10:31.56 |
| | K at 45 because that's the best angle and we use a lot of K | 10:32.15 |
| Robin_Watts | ok, so I would have expected the sizes to change according to angle... | 10:34.02 |
| kens | The ceel sizes ? I don't think I woudl expect them to be different | 10:34.18 |
| | Or some other size ? | 10:34.23 |
| Robin_Watts | For an angle of 0, with 256 levels, I get a 16x16 cell. | 10:37.50 |
| kens | Yes | 10:37.56 |
| Robin_Watts | For an angle of 25, with 256 levels, can I get away with a 16x16 cell too ? | 10:38.08 |
| kens | 16x16 = 256 gray levels | 10:38.11 |
| | Like I said, the cell sizwe won't change | 10:38.21 |
| Robin_Watts | ok. ta. | 10:38.26 |
| kens | The actual screen angle won't be precisely what you requested, it'll be approxiamte. To get actual angles, you need to use accruate screens, which involves a screen cell much bugger | 10:38.56 |
| | Beyond this point you probably need to talk to Michael :-) Its been a very, very long time since I did any screening work | 10:39.51 |
| Robin_Watts | yeah, it's like totally stochastic, dude. | 10:46.53 |
| | Time to wait for mvrhel. | 10:46.59 |
| kens | Oh, I thought gen_stochastic would produce that. | 10:47.05 |
| Robin_Watts | $ debug/gen_ordered.exe -a 15 -d 0 -f raw -q256 -s32 -l 324 | 10:47.18 |
| kens | I was expecting gen_ordered to produce a standard threshold array | 10:47.18 |
| Robin_Watts | Warning this lpi is not achievable! | 10:47.19 |
| | Resulting screen will be poorly quantized | 10:47.21 |
| | or completely stochastic! | 10:47.22 |
| kens | Oh | 10:47.26 |
| | Maybe change the -s parameter ? | 10:47.40 |
| | Or fewer grays | 10:47.53 |
| Robin_Watts | The frubble wart will be intersactually twangled. | 10:47.55 |
| | I'll wait for mvhrel rather than prod it with random guesses. | 10:48.19 |
| kens | :-) | 10:48.23 |
| | Like I said, its not a tool I'm familiar with | 10:48.36 |
| Robin_Watts | Thanks for you help anyway. | 10:48.47 |
| kens | I could probably figure it out by debugging the code, but waiting for Micahel is probably quicker :-) | 10:49.20 |
| | chrisl you back yet ? | 10:49.50 |
| giomac | Hi, i've got problems with many Centos machines with CUPS - most of them are unable to print PDF's, none of them are able to print to remote CUPS instance, some of them are unable to print to the network printer: cupsd[17574]: GPL Ghostscript 9.07: Unrecoverable error, exit code 1 | 11:55.56 |
| | I've tried to debug issues as much as possible, upgraded cups, filters, ghostscript, dependendcies etc (recompiled, RPM's dependecnies etc) | 11:56.40 |
| | none worked | 11:56.42 |
| | where can i start? | 11:56.54 |
| | common thing are Canon printers, UFRII drivers | 11:57.45 |
| kens | That's rather hard to say | 12:00.07 |
| | Why do you think it might be a Ghostscript problem ? | 12:00.15 |
| | giomac : have you got CUPS logs to look at ? Have you discussed this with teh CUPS developers ? | 12:01.09 |
| giomac | thing is, i had to strace cups to get logs, because only detail i see in cups logs is "Unrecoverable error, exit code 1" | 12:02.57 |
| | for both 9.07 and latest versions | 12:03.14 |
| kens | The first thing you need to do, is to get the log of the back channel output from Ghostscript. The 'unrecoverable error' will be the tail end of it, that's missing any useful information as to the cause of the problem. | 12:03.14 |
| | You should also get a PDF file which fails and make that available to us. | 12:03.32 |
| | When you can get a CUPS log that should also tell you what command line is being used to start Ghostscript, we need that too | 12:03.57 |
| giomac | yes, that's what i did via strace, now i'm simulating and collecting that again | 12:04.47 |
| kens | if that's all you got from strace then its not the complete log | 12:05.04 |
| | There should be more there I would have thought | 12:05.52 |
| | But shout when you have a file and a command line I can look at | 12:06.07 |
| HenryStiles | giomac: /etc/cups/cupsd.conf - LogLevel should be set to debug, then cups will write a log somewhere, you can "google" the reset | 12:09.37 |
| kens | Ah thanks HenryStiles I've been searching our iRC logs for that info.... | 12:10.00 |
| HenryStiles | that's ubuntu but I imagine centos is similar | 12:10.13 |
| kens | I think CUPS is all the same, though the spcific location might vary I guess. Probably not that much | 12:10.34 |
| giomac | it doesn't print nor complete output, nor command run anyway, that's why i had to strace process to see execve called :)) | 12:10.35 |
| kens | Yes, but it should (I htink) log all the Ghostscript back channel output I think. It also will (I'm sure of this) give you the command line that Ghostscript was invoked with | 12:11.12 |
| giomac | increasing ripcache didn't help too | 12:11.19 |
| kens | We need that, and a file which failed | 12:11.20 |
| giomac | sure | 12:11.36 |
| kens | The back channel output would be nice, but the example file and command line are rather more important | 12:12.13 |
| giomac | i've got d file from cups and command line options | 12:15.23 |
| kens | Hmm, I'n not sure what a 'd' file is.... | 12:15.38 |
| | oh typo ? | 12:15.52 |
| giomac | no, not a type: | 12:16.01 |
| | cups sends file to gs, it reads it from input, this file is stored with name starting with "d" letter | 12:16.38 |
| kens | OK | 12:16.48 |
| | inefficient, since GS will then immediately create a temporary file before processing it (for PDF), but there you go | 12:17.19 |
| | Anywya, so if you maek the file available and tell us the command line, we can give it a try | 12:17.47 |
| giomac | cups is adding "-" in the end, which causes it to dump both normal output and error :) | 12:19.42 |
| chrisl | kens: back now | 12:20.25 |
| kens | Welcome back | 12:20.32 |
| chrisl | I wasn't out *that* long..... | 12:20.59 |
| kens | giomac, not sure I ffollow you, are you saying that you now see what the problem is ? | 12:21.04 |
| giomac | yes, one guy had same problem, but i didn't catch it, now i was able to reproduce it by accident, i thought i had just a similar issue | 12:22.31 |
| | i'll check it again... | 12:22.44 |
| | lms | 12:22.47 |
| | nope, it's a bit different issue | 12:29.34 |
| | here's the case: | 12:29.37 |
| | https://joshuakugler.com/cups-ghostscript-and-memory-errors-oh-my.html | 12:29.38 |
| | i've got file and command line | 12:29.51 |
| kens | minute | 12:29.57 |
| | Where's the input file ? | 12:31.25 |
| | Right so I see numerous problems in the back channel | 12:31.51 |
| giomac | i have it | 12:32.05 |
| kens | "Some glyphs of the font DejaVuSans requires a patented ... | 12:32.12 |
| | Then Error: /unregistered in --run-- | 12:32.30 |
| | I'm going to need the input file | 12:32.53 |
| giomac | where to send? | 12:33.05 |
| kens | Well you can put it somewhere public, or open a bug report | 12:33.16 |
| | You can attch files to bug reports | 12:33.35 |
| giomac | https://www.dropbox.com/s/vwmt2h3v8jque39/d00157-001?dl=0 | 12:35.54 |
| kens | Your blog seems to indicate that the exact same invocation of gs (except for filename instead of stdin works.... | 12:36.15 |
| giomac | https://paste.fedoraproject.org/paste/U5fgyWqG0lP8nTtJ2F8Xuw | 12:37.38 |
| kens | Well, the file you;ve sent me is neither a PostScript nor a PDF file | 12:37.40 |
| giomac | same in that case, but it's printed | 12:38.33 |
| | this is what is sent to gs | 12:38.38 |
| kens | If you send that file to Ghostscript ti will throw an error | 12:38.57 |
| | Because its not PostScript or PDF | 12:39.04 |
| giomac | so, for gs is it's REQUIRED to have %PDF or %!PS header? | 12:39.58 |
| kens | When I run that file through Ghostscript it gives me an entirely expected error "Error: /undefined in <binary>" | 12:40.05 |
| | giomac No | 12:40.14 |
| | But the content *has* to be either PostScript or PDF or the interpreter doesn't know what to do with it. | 12:40.32 |
| | The file you;ve sent me is neither | 12:40.39 |
| | So, unsurprisingly, t throws an error. | 12:41.02 |
| | Note that its not the same error as you pasted. Given the log file I do not beleive this is the file that was sent to Ghostscript | 12:41.23 |
| giomac | this is the same file, 100% and i've got same error with that command line | 12:42.00 |
| kens | The file I get from your dropbox begins 0xCD 0xCA 0x10 0x00 0x00 0x6B | 12:42.36 |
| | That's not PostScript and its not PDF | 12:42.44 |
| giomac | with a "gs d00157-001" i'm getting Error: /undefined in | 12:42.45 |
| | i'll check with the cups guy, why does it send file to the ghostscript | 12:43.05 |
| mvrhel_laptop | Robin_Watts: ok I am back if you want to talk about screens | 15:13.32 |
| Robin_Watts | Thanks. | 15:13.41 |
| | So I looked at gen_ordered, and it needs all sorts of things I don't understand. | 15:14.00 |
| mvrhel_laptop | Robin_Watts: you should be able to generate some simple ones | 15:14.22 |
| | with it | 15:14.23 |
| | let me look at the readme | 15:14.33 |
| Robin_Watts | After a bit of googling and consultation with kens, I figured that angles of (K 45º, C 15º, M 75º, Y 0º) would be good. | 15:14.48 |
| mvrhel_laptop | yes | 15:14.55 |
| | so that is the target_angle | 15:15.34 |
| | dot_shape just make round | 15:15.41 |
| | you want ps output I think | 15:15.52 |
| Robin_Watts | Debug/gen_ordered.exe -a 0 -s 16 -d0 -f raw looked plausible. | 15:16.17 |
| | similarly: Debug/gen_ordered.exe -a 45 -s 16 -d0 -f raw | 15:16.29 |
| | but: | 15:16.50 |
| | $ Debug/gen_ordered.exe -a 15 -s 16 -d0 -f raw | 15:16.53 |
| | Warning this lpi is not achievable! | 15:16.54 |
| | Resulting screen will be poorly quantized | 15:16.56 |
| | or completely stochastic! | 15:16.57 |
| | The frubble wart will be intersactually twangled. | 15:17.18 |
| mvrhel_laptop | ok let me run this thing.... | 15:17.36 |
| | Robin_Watts: so don't specify -s instead say you have -r 600 (the device resolution) and maybe a desired lpi of 33 | 15:20.56 |
| | That should work better for you | 15:21.06 |
| Robin_Watts | Ok. I have no clue what lpi "means" | 15:22.33 |
| | "lines per inch" obviously. | 15:22.48 |
| mvrhel_laptop | lines/inch | 15:22.48 |
| Robin_Watts | but I have limited understanding in what that means. | 15:23.01 |
| | At some point adding some "here are some suggested calls to make screens" to the README might be good. | 15:23.26 |
| mvrhel_laptop | think of it as a measure of how far apart the dot centers are | 15:23.42 |
| Robin_Watts | It seems odd to have both lpi and resolution default to the same value. | 15:23.42 |
| mvrhel_laptop | the printer resolution is greater than the dot center spacing | 15:23.55 |
| | as the dots grow they connect | 15:24.09 |
| Robin_Watts | When one would assume that they should be significantly different in most cases. | 15:24.13 |
| mvrhel_laptop | Robin_Watts: hey, the documentation is almost as good as MuPDF ;) | 15:24.55 |
| Robin_Watts | mvrhel_laptop: Is there a 200 page book I can read on this? :) | 15:25.16 |
| mvrhel_laptop | Robin_Watts: so does a little table display when you run the program? | 15:25.44 |
| Robin_Watts | mvrhel_laptop: A table ? No. | 15:26.05 |
| mvrhel_laptop | It should show the actual angle achieved and the LPI and the number of quantization levels | 15:26.06 |
| Robin_Watts | I get no output at all. | 15:26.20 |
| mvrhel_laptop | hmm maybe ray turned that off | 15:26.22 |
| Robin_Watts | I just get a file dumped out. | 15:26.26 |
| mvrhel_laptop | he did some changes | 15:26.27 |
| | hold on | 15:26.30 |
| Robin_Watts | Ah. -v ? | 15:26.32 |
| mvrhel_laptop | yes | 15:26.35 |
| | -v 1 | 15:26.49 |
| | -v1 | 15:26.51 |
| | that should show you some interesting things that are traded off in terms of resolution vs quantization | 15:27.17 |
| | I think it should be on -v1 by default | 15:27.42 |
| | Robin_Watts: I will see if I can improve the docs in this | 15:28.48 |
| | Maybe write a bit of halftone theory in there | 15:29.04 |
| | It is a bit sparse.... | 15:29.23 |
| | but first... grabbing my data off of chains | 15:29.59 |
| Robin_Watts | Debug/gen_ordered.exe -a 15 -l 33 -q 256 -s16 -d 0 -f raw -v 1 appears to have gone into an infinite loop. | 15:30.22 |
| mvrhel_laptop | hmm don't specify -s with that command line | 15:31.20 |
| | that is a bug though... | 15:31.29 |
| ray_laptop | "find fonts in your fonts" Clearly my coffee hasn't hist yet :-/ | 15:32.02 |
| mvrhel_laptop | maybe specify a printer resolution | 15:32.05 |
| | too | 15:32.08 |
| | default is 300 | 15:32.15 |
| | I think | 15:32.16 |
| | let me try this though | 15:32.27 |
| | oh I see | 15:33.23 |
| | Robin_Watts: obviously this need someone poking at it like yoy | 15:33.48 |
| | you | 15:33.50 |
| Robin_Watts | mvrhel_laptop: Idiot Testing(TM). | 15:34.05 |
| | ooh, and another question... | 15:34.40 |
| ray_laptop | Robin_Watts: if you want to use the screens with Ghostscript, -fps is best since GS can load them for you. | 15:35.06 |
| Robin_Watts | I'm trying to get the gs integration of the halftoning stuff working (being careful to mention no names, cos public channel etc) | 15:35.20 |
| | ray_laptop: This is not for gs. It's for the simple standalone test harness. | 15:35.42 |
| ray_laptop | Robin_Watts: OK. | 15:35.54 |
| Robin_Watts | And so I'm looking at mvrhel's integration. | 15:36.04 |
| | In halftone_init, you do: | 15:36.15 |
| | if (penum->pgs != NULL && penum->pgs->dev_ht != NULL) { | 15:36.34 |
| | ctx = ipa_init(&ipa_allocs, penum->memory->non_gc_memory); | 15:36.35 |
| | if (ctx == NULL) | 15:36.37 |
| | return NULL; | 15:36.38 |
| | penum->ipa_ctx = ctx; | 15:36.40 |
| | } | 15:36.41 |
| | If penum->pgs == NULL || penum->pgs->dev_ht == NULL then you fall through and try and halftone without having created the lib instance. | 15:37.06 |
| | Am I right in thinking that penum->pgs and penum->pgs->dev_ht should NEVER be NULL at this point? | 15:37.31 |
| ray_laptop | Robin_Watts: should you be mentioning ipa here ? | 15:55.31 |
| Robin_Watts | ray_laptop: I thought it was OK since ipa didn't mean anything to anyone. | 15:55.59 |
| ray_laptop | true | 15:56.08 |
| Robin_Watts | but I've been scolded by mvrhel and StevePhillips already :) | 15:56.12 |
| mvrhel_laptop | Robin_Watts: so the results with the new run are a little surprising. The Altona Visual file in particular. I may redo this all one more time to verify that these results are correct | 16:28.07 |
| | Realize 2 things changed here | 16:28.24 |
| Robin_Watts | mvrhel_laptop: No benefit? Or greater benefit than you expected? | 16:28.31 |
| mvrhel_laptop | 1) I am now going to a different output CMYK color space forcing more conversions especially for the visual file | 16:28.52 |
| | 2) we slowed the clock | 16:28.59 |
| Robin_Watts | Right. | 16:29.07 |
| mvrhel_laptop | The visual file is showing 80 + percent improvment | 16:29.14 |
| Robin_Watts | Well, that's a good thing :) | 16:29.28 |
| mvrhel_laptop | yes | 16:29.31 |
| | The images file is also interesting | 16:29.41 |
| | If I use the min value I am around 8 percent | 16:29.52 |
| | which is similar to before | 16:30.03 |
| Robin_Watts | min value? 8% of what? | 16:30.14 |
| mvrhel_laptop | if I use the average we are up 18 percent | 16:30.16 |
| | fastest time of 10 for each run with a particular thread number used | 16:30.43 |
| | hence the min | 16:30.49 |
| Robin_Watts | D'Oh. I see. sorry. | 16:30.52 |
| mvrhel_laptop | vs the avg. over 10 | 16:30.54 |
| | I am going to run the visual test again just to make sure | 16:34.54 |
| | since that one is of the chart | 16:35.00 |
| | s/of/off/ | 16:35.22 |
| Robin_Watts | Is it worth doing some quick profiles on your desktop machine to check that 80% is reasonable ? | 16:35.35 |
| mvrhel_laptop | well I can do a quick check on chains | 16:36.08 |
| | too | 16:36.10 |
| | just a single run | 16:36.13 |
| | good point | 16:36.18 |
| Robin_Watts | runs on chains aren't profiles. | 16:36.27 |
| mvrhel_laptop | no, but I will have the timing values | 16:36.36 |
| | an verify I did not use the wrong file :) | 16:36.55 |
| | s/an/and/ | 16:36.59 |
| | or setting | 16:37.07 |
| | but I can do it on my machine here too | 16:37.21 |
| | as another sanity check | 16:37.27 |
| Robin_Watts | Right, but if you run it on your desktop, and you find that the old version only spends 20% overall in the cms code, then an 80% increase overall seems unlikely ? | 16:37.30 |
| mvrhel_laptop | ah I see | 16:37.41 |
| | it spends about 50 percent of its time in lcms | 16:38.20 |
| | for that file from my earlier check | 16:38.30 |
| | actually no | 16:39.00 |
| | 42 percent | 16:39.07 |
| Robin_Watts | So, I'm confused. | 16:39.19 |
| mvrhel_laptop | 30 percent creating links, 12.5 percent transforming colors | 16:39.24 |
| | Me too ;) | 16:39.29 |
| Robin_Watts | If the old code took 100 seconds to run, and it now takes 20 seconds to run, that'd be an 80% increase ? | 16:39.38 |
| mvrhel_laptop | yes | 16:39.45 |
| | and 42 percent of the run time is spent in lcms | 16:40.16 |
| Robin_Watts | So if the old code was spending 42 seconds in cms code out of that 100 seconds, even if we optimise that all away to 0, the best we can hope for is a 42% speedup. | 16:40.33 |
| mvrhel_laptop | ah. one thing is I may have been looking at that with the new code.... | 16:41.01 |
| | i.e. 42 percent with lcms-mt | 16:41.14 |
| | let me go back and get all of this straight | 16:41.31 |
| Robin_Watts | Right. Knowing the percentage of time spend in the code in the original would be a really good thing to know independently of all this. | 16:41.36 |
| | (cos it gives us a "maximum possible" figure) | 16:41.46 |
| mvrhel_laptop | yes | 16:41.46 |
| | right | 16:41.49 |
| Robin_Watts | Gah. I've clearly got something screwed with this halftoning code. | 16:42.16 |
| mvrhel_laptop | yes. I was definitely in the new code when I had those numbers | 16:42.16 |
| | I have to head out for a bit to run a few errands | 16:42.28 |
| Robin_Watts | the 90 and 270 degree rotations are flipped. | 16:42.30 |
| mvrhel_laptop | oops | 16:42.35 |
| Robin_Watts | HTF have I managed that :) | 16:42.47 |
| ray_laptop | if the old code took 100 sec and the new code takes 55 sec, THAT's an 80% performance increase (1.8x) | 17:01.27 |
| | we should state in terms of performance increase, not time decrease. | 17:02.18 |
| | that's how we would look at it for printer PPM | 17:02.44 |
| | or to avoid confusion just state performance is 1.8 times | 17:04.13 |
| Robin_Watts | An 80% improvement is a 5 fold improvement. (We do 5 pages in the time previously taken to do 1) | 17:06.40 |
| | Michael is clear in the paper about his claims, so whatever is fine, I feel. | 17:07.32 |
| kens | Robin_Watts : you still about ? | 18:41.29 |
| | OK for the logs then. I discovered I didn't have MuPDF on my laptop, so I followed the git clone instructions on mupdf.com. Opened the VS solution file, updated it to VS 2008. Selected build solution | 18:43.21 |
| | 13 failed to build. Problems all of the form: | 18:43.56 |
| | 2>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\stdlib.h(599) : error C2485: '__restrict' : unrecognized extended attribute | 18:43.56 |
| | source line in stdlib.h is : | 18:44.33 |
| | _Check_return_ _Ret_opt_bytecap_x_(_NumOfElements* _SizeOfElements) _CRTIMP _CRT_JIT_INTRINSIC _CRTNOALIAS _CRTRESTRICT void * __cdecl calloc(_In_ size_t _NumOfElements, _In_ size_t _SizeOfElements); | 18:44.33 |
| | Kind of puzzled by that, any ideas ? | 18:45.07 |
| | FWIW every line in stdlib.h that includes _CRTRESTRICT seems to throw the error | 18:47.14 |
| Robin_Watts | kens: For the logs, I suspect it's the #define restrict __restrict in fitz/system.h | 22:28.19 |
| | kens: Probably line 158 should be 1600 ? | 22:29.23 |
| | Forward 1 day (to 2018/03/31)>>> | |
Log of #ghostscript at irc.freenode.net.