| | <<<Back 1 day (to 2012/11/05) | 2012/11/06 |
| sebras | is back. | 08:32.51 |
| kens | Hi sebras | 08:34.50 |
| sebras | kens: hey! | 08:47.57 |
| kens | You were on holiday ? | 08:48.21 |
| sebras | kens: yes -- icelandairwaves.is | 08:48.33 |
| kens | THought so, did you have a good time ? | 08:48.44 |
| sebras | kens: most of the time -- yes. :) unfortunately I got sick the last day so I missed the Sigur Rós concert that was the biggest reason for me going there. :-/ | 08:49.31 |
| kens | Oh, not so great :( | 08:49.45 |
| sebras | kens: I'm still confused and half asleep, so be wary of any commits I make today. ;) | 08:50.16 |
| kens | Not my problem, I don't think you commit to my area :-) | 08:50.31 |
| jaqwii | Hey - Any hardcore gs'ers here that can help me understand why my rendering of pdf pages to tiff is non-deterministic? I need a lossless version of each page that is always rendered in the same way | 09:04.27 |
| kens | That is how it should be, unless you have used (for example) the rand operator | 09:04.49 |
| tkamppeter | Robin_Watts_, you wanted to tak with me yesterday? | 09:05.53 |
| jaqwii | is that like a seed? | 09:05.59 |
| kens | jaqwii : Its an opertor in the PostScript language, its *highly* unlikely that your PostScript programs are using it | 09:06.28 |
| | And for PDF< I think its impossible | 09:06.49 |
| | But you haven't actually given us any ideas to work on. | 09:07.09 |
| | What version of GS, what kind of TIFF< what exactly is the nature of the non-deterministic behaviour (whats is the difference in teh output) | 09:07.36 |
| jaqwii | so no matter what operators i do, a conversion from pdf to tiff will always have some random rendering behaviour | 09:07.49 |
| | ? | 09:07.51 |
| kens | No. It most definitely should not | 09:08.09 |
| | But see above, I have no idea yet what your actualproblem is | 09:08.23 |
| chrisl | jaqwii: how are you comparing the tiff output? | 09:08.23 |
| jaqwii | gs (9.06) tiff24nc | 09:08.44 |
| | chrisl: yes | 09:08.49 |
| chrisl | huh? *How* are you establishing the outputs are different? | 09:09.18 |
| jaqwii | I do however also have parameters like TextAlphaBits, GraphicsAlphaBits, DOINTERPOLATE | 09:09.22 |
| | I use imagemagick compare | 09:09.35 |
| | on the tiff files | 09:09.39 |
| kens | OK so we can forget screening. So what exactly is the difference you are seeing | 09:09.39 |
| | ANd what does it show as the difference ? | 09:09.52 |
| | Is it comparing the metadata ? | 09:10.00 |
| jaqwii | based on the diff ouput image, the entire image have small changes. around images and text | 09:10.23 |
| kens | Well, if the input is identical, the output should also be identical, there ios no stochastic noise in a contone output | 09:10.59 |
| | Can you share an example ? | 09:11.06 |
| | PDF and TIFFs | 09:11.11 |
| jaqwii | my guess was that one of the parameters i use have random behavior, if I just run the same command twice then they are equal, but if I run it again after some time it seems to differ | 09:11.11 |
| | the entire command (example): gs -r207.81818962097168 -dAutoRotatePages=/None -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dCOLORSCREEN -dDOINTERPOLATE -sFONTPATH=[path] -dUseCropBox -dNOPAUSE -dNOPAGEPROMPT -dBATCH -sDEVICE=tiff24nc -dFirstPage=19 -dLastPage=19 -sOutputFile=[outputfile] [inputfile] | 09:14.24 |
| kens | -dCOLORSCREEN is pointless wiht contone output | 09:15.16 |
| | But shouldn't cause any harm | 09:15.30 |
| | We do have some known files which cause non-deterministic output, but these are unusual, it seems unlikely that you are encoutnering them regularly. But without seeing some examples its going to be hard to tell. Why do you care anyway ? | 09:17.28 |
| chrisl | jaqwii: there are some things to check: which version of Ghostscript are you using? Did you build from source, or are you using a binary distribution, and from where? Eliminate the interpolation and alpha-bits params one at a time, and see if one of them is causing the problem. Finally, try a device other than tiff (ppmraw, for example) to see if the issue is specific to the tiff device, or in the "core". | 09:25.11 |
| jaqwii | thanks guys - i'll give it a go with the format and parameters, since it seems to be a general issue for me. | 09:28.18 |
| chrisl | Hmm, not enough of a problem to actually impart any useful information, then....... | 09:33.12 |
| kens | Apparently not... | 09:33.23 |
| | He did say he was using 9.06 though | 09:33.34 |
| chrisl | Yes, so he did. But I certainly don't want to start stabbing in the dark to reproduce the issue :-( | 09:34.40 |
| kens | exactly, I want to *see* it first | 09:35.09 |
| chrisl | Hmm, I'm getting a crash in my fapi code, with ps2write - and I can't see how it's connected to FAPI.... :-( | 09:36.37 |
| kens | I can look into it if you like | 09:36.53 |
| chrisl | Well, it's not *in* the fapi code, it's on the fapi branch | 09:36.57 |
| kens | Yeah I figured that, presumably its a public branch though ? | 09:37.16 |
| chrisl | It's on my personal repository | 09:37.31 |
| kens | Umm, does that mean I can't see it ? | 09:37.40 |
| | already venturing into unknown territory with Git... | 09:37.59 |
| chrisl | kens: sorry, phone call. Yes you can see it. Let me run the thing with valgrind first, see if I have missed something obvious | 09:40.28 |
| kens | OK, let me know if you want me to look at it | 09:40.40 |
| | I'm just messing about with colour stuff at the moment | 09:41.03 |
| chrisl | Well, what's happening is that the device is missing (NULL) in gx_image_fill_masked(), having been called (eventually) via pdf_text_process()...... | 09:42.48 |
| kens | could be falling back to a type 3 | 09:43.49 |
| | Its about the only way you can get there from text_process | 09:44.35 |
| chrisl | kens: so, it's going into gx_image_fill_masked() which then calls gx_image_fill_masked_start() and that doesn't set the device to use - which looks wrong.... | 09:47.02 |
| kens | Sort of sounds wrong, which test file is the culprit ? | 09:47.29 |
| chrisl | Bug6901014_CImg_flyer.pdf | 09:48.13 |
| kens | Oh good, a nice simple one :-( | 09:48.21 |
| | Give me a minute | 09:48.30 |
| | The case must be going into the pattern colour code ? | 09:50.07 |
| chrisl | kens: if you look at gx_image_fill_masked_start(), there is a route through that code which doesn't set cdev, but doesn't return an error, either. | 09:50.22 |
| kens | otherwise it sets *cdev=dev and returns | 09:50.24 |
| | chrisl if its a pattern colour but no spec_op yes | 09:50.47 |
| chrisl | Yes, looks that way | 09:51.10 |
| kens | For me we never hit that code | 09:51.22 |
| | But the PDF interpreter throws a warning about the file being unbalanced | 09:51.47 |
| chrisl | Hmmm, strange. I can't see how the fapi code would influence that..... | 09:52.05 |
| kens | Seems like gx_dc_is_pattern2_color or gx_dc_is_pattern1_color_clist_based are never true for me | 09:53.11 |
| | So I never get to the spec_op test | 09:53.35 |
| | Of course this is WIndows, not Linux | 09:53.48 |
| chrisl | Again, shouldn't matter | 09:54.12 |
| kens | Only if its some sort of odd memory thing | 09:54.29 |
| | Having sadi that, by inspection there *is* indeed a problem there as you noted | 09:54.46 |
| | You can probably fix it by putting an "else *cdev=dev;" in there, but I'd like to understand why its getting there for you | 09:55.25 |
| chrisl | I did that, but the output isn't quite right, I think | 09:55.48 |
| kens | TO be honest, I'm not totally surprised, since its is apparently processing a pattern colour space, that it 'shouldn't' be | 09:56.17 |
| chrisl | So there is something else going on :-( | 09:56.25 |
| kens | It kind of looks that way yes | 09:56.36 |
| | You sem to be prcoessing text in a pattern space, and I'm not | 09:56.50 |
| chrisl | I guess I need to try to cut down the file - oh joy :-( | 09:57.39 |
| kens | It could mean thst your code is falling bcak to a fill where mine does not (hence handling the pattern at a higher level) | 09:57.40 |
| | Reducing the file woudl help a lto, but.... | 09:57.57 |
| | It may be transparency related.... | 09:58.04 |
| | I admit I cna't see any text that looks like it should be in a pattern space, but its not possible to be sure from a visual inspection | 09:58.43 |
| chrisl | Trouble is, I just can't see how the fapi code can be influencing the color space, or whether we fall back to bitmap glyphs in ps2write | 09:59.04 |
| kens | Some fo the text lies on top of a shading though | 09:59.04 |
| | chrisl it could influence the fallback, possibly | 09:59.18 |
| | or rather, conceivably | 09:59.30 |
| | From what I see here it is indeed entrering the type 3 bitmap fallback case | 10:00.07 |
| chrisl | On master? | 10:00.19 |
| kens | Yes | 10:00.26 |
| | I get to the fill code several times, but never with a pattern colour space | 10:00.38 |
| chrisl | Okay, I will see if I can fathom where the pattern is appearing from..... | 10:01.42 |
| kens | You can catch it doing this by stopping at teh 'default_impl' goto label | 10:01.50 |
| | in pdf_text_process in gdevpdtt.c | 10:02.03 |
| | THis is, unfortunately, one of the hairiest areas in pdfwrite | 10:02.15 |
| | chrisl its a composite font (presumably CID) which we don't handle in ps2write, so it falls back | 10:06.26 |
| | pdfwrite of course will handle it as a CIDFont and so doesn't execute teh fallback code | 10:06.51 |
| | Just checked the original file and all the fonts are CIDFOnts, so all the text will end up going through here | 10:07.20 |
| chrisl | Yeh, I see that. At least the first bunch of times through the deafult_impl code, it's not a pattern space set | 10:07.21 |
| kens | Normally I put a count breakpoitn on the entrpoint (pdf_text_process) wiht a large value, run to the crash and see how many hits the breakpoitn got, then set the hit counter back to that value. Don't knwo if you cna do that with gdb | 10:08.23 |
| chrisl | Yeh, I've just done that. The iteration before the crash, it's a "flat" color space, next time through, it's a pattern, and crashes | 10:09.11 |
| kens | OK so how many times do you get to pdf_text_process ? | 10:09.31 |
| | Its hard to see how you can be getting here with a pattern colour though | 10:10.02 |
| chrisl | Well, I'm breaking just below the default_impl label, it crashes on the 237th hit | 10:10.23 |
| kens | Hmm, thats a lot, jutst a moment | 10:10.42 |
| | For me the 237th iteration doesn't even go through the fill code, which suggests that its using cached data | 10:12.49 |
| chrisl | Hmm, odd..... | 10:13.54 |
| kens | Just walking through show_proceed on the 237th iteration | 10:15.33 |
| | In this case is_pure_color is 0 | 10:16.26 |
| | and teh colour is a type 2 pattern (aha!) | 10:16.46 |
| | gx_lookup_cached_char returns 0 so it's not cached (IIRC) | 10:18.07 |
| chrisl | Now I'm confused | 10:18.34 |
| kens | Me too, somewhat | 10:18.41 |
| | I have an uncached glyph in a pattern space, and yet its not getting to the fill, give me a bit more time, I'mstill tracking it | 10:19.01 |
| | Its definitely gone to the 'no_cache' label in show_proceed | 10:19.30 |
| | ANd now I'm off to procs.build_char | 10:20.01 |
| | Oh which always returns 1 | 10:20.22 |
| | so we call show_cache_setup | 10:20.40 |
| | and return TEXT_PROCESS_RENDER | 10:20.59 |
| | back in ps2write we install the PS charproc acccumulator (ah ;-) | 10:21.31 |
| | Nope, looks like we decide we can't do outlines either | 10:22.12 |
| | Err, mayeb that's upside down in sense, just a moment | 10:22.27 |
| | Hmm, well that code confuses me, and I wrote it :-( | 10:23.22 |
| | But it looks like we've decided we need to render the glyph | 10:23.48 |
| | So now I'm in op_show_continue in zchar.c, executing the TEXT_PROCESS_RENDER case | 10:24.34 |
| | So it looks like we are pushing the font and glyph onto the stack and then executing BuildChar | 10:25.31 |
| Robin_Watts_ | http://www.kickstarter.com/projects/1461411552/elite-dangerous | 10:26.00 |
| chrisl | Which should be zFAPIBuilgGlyph | 10:26.07 |
| kens | Saw it on the Register this morning | 10:26.11 |
| | chrisl, I hope so, just a moment | 10:26.25 |
| | yes, zFAPIBuildGlyph | 10:27.09 |
| | which onl ycalls FAPI_char | 10:27.20 |
| | I'm going to skip over that and look only at the return value | 10:27.42 |
| chrisl | Okay, so FAPI decides it needs to create an outline - which is interesting..... | 10:27.58 |
| kens | The return code is '5' | 10:28.00 |
| | From FAPI_do_char | 10:28.13 |
| chrisl | So, there's a CDevProc | 10:28.15 |
| kens | There always is with PDF files | 10:28.24 |
| chrisl | Yes | 10:28.29 |
| kens | The PDF interpreter uses it to positionh the glyphs IIRC | 10:28.34 |
| chrisl | It does, yes | 10:28.59 |
| | So, in my code, FAPI decides it needs to produce an outline | 10:29.35 |
| kens | Is that the return code of 5 ? | 10:29.55 |
| chrisl | Yes | 10:30.17 |
| kens | OK so that's waht I see too | 10:30.29 |
| chrisl | Oh, No, the return code 5 is for teh CDevProc | 10:30.34 |
| kens | OK then its the CDevProc I'm running | 10:30.48 |
| | I think I just reached the end | 10:31.17 |
| chrisl | So it should call setcachedevice (or similar), and then the fapi "finish_char" thingy - can't remember the name | 10:32.15 |
| kens | Not sure, still running this insanely ocmplex CDevProc | 10:32.38 |
| | Aha, now I'm in zsetcachedevice2 | 10:33.11 |
| | Which takes me through to pdf_text_set_cache | 10:33.47 |
| | And on to gs_text_set_cache | 10:34.26 |
| | eventually to gx_show_text_set_cache | 10:34.51 |
| chrisl | When you get to fapi_finish_render() step through there, and check if you're got a bitmap or outline glyph | 10:35.04 |
| kens | Still debugging :( | 10:35.14 |
| | about to go to set_cache_device | 10:35.26 |
| | never called the fapi code. I best rerun that | 10:36.09 |
| | Oh no, here we are | 10:36.22 |
| chrisl | I think we're getting an outline glyph there, too | 10:36.43 |
| kens | so, into fapi_finish_render_aux | 10:36.45 |
| | So I'm calling I->get_char_raster | 10:37.14 |
| | dive in or step over ? | 10:37.26 |
| chrisl | step over | 10:37.34 |
| kens | I->use_outline is 1 | 10:37.43 |
| chrisl | Yes, that's what I expect. | 10:37.59 |
| kens | OK about to go to gs_fill | 10:38.25 |
| | just loaded the colour and its still a type 2 pattern | 10:39.29 |
| | So now I'm in gdev_pdf_fill_path | 10:40.00 |
| | Ah, looks like we get a rangecheckerror which is a hideous hack that means 'high level pattern' | 10:41.00 |
| | So we go through convert_to_image | 10:41.23 |
| | Hmm, chrisl is 'convert_to_image' true or false for you here ? | 10:42.17 |
| chrisl | I'm long past that just now, but....... | 10:42.42 |
| kens | OK never mind | 10:42.52 |
| | Its just that things start to get really complex now because we (potentially) install the masked image converter | 10:43.18 |
| chrisl | I've found the difference in the font world - when we get to show_update(), in the master code penum->width_status == sws_no_cache, but on the fapi branch is sws_cache | 10:43.34 |
| kens | Well it will certainly take different pths through the code in that case | 10:44.06 |
| | I guess I'll leave it to you for now | 10:44.32 |
| chrisl | With sws_no_cache we skip the "image_cached_char" call completely, and that's where teh crash happens..... | 10:45.17 |
| kens | I htink I would expect it to be not cached if its filled with a pettern... | 10:45.44 |
| chrisl | I'd have thought it was more to do with pdfwrite/ps2write, and the way it bypasses the normal glyph cache | 10:46.36 |
| kens | I'm unsure about that, we *do* use the cache | 10:46.54 |
| | sometimes.... | 10:47.09 |
| chrisl | Bingo! I'd left some debug code in, and it was fouling up the decision whether to cache or not - it was, effectively, trying to switch to cached rendering part way through the process - phew! | 10:59.01 |
| kens | Excellent, glad you found iot | 10:59.18 |
| chrisl | I keep forgetting how places we actually "decide" whether to cache or not :-( | 10:59.52 |
| kens | Its very democratic, everyone gets a chance to decide :-) | 11:00.30 |
| chrisl | Except everyone also has to agree, or all hell breaks loose! | 11:00.51 |
| Robin_Watts_ | tkamppeter: ping | 12:47.22 |
| | I was indeed looking for you yesterday. | 12:47.32 |
| | We have some code to generate dither patterns for inkjet printers that I'd like to be able to test. | 12:48.05 |
| | I have a Canon MX310 here, that is supposedly supported by Gutenprint. | 12:48.23 |
| | What I'd like to be able to do is to generate some dithered output (currently I'm making CMYK pams) and get that sent to my printer with as little transformation as possible (no redithering, no rescaling, no centreing etc) | 12:49.18 |
| | I was hoping there might be some way that I could generate a cups raster and then somehow inject that into the cups queue? Or call some cups2canon thing? | 12:50.10 |
| ray_laptop | two kids home sick today :-( | 15:21.21 |
| Robin_Watts_ | Thank heavens for having an office, eh? :) | 15:22.57 |
| henrys | the politics was too much for them ;0( | 15:33.29 |
| | it's certainly getting me sick - glad it's over today. | 15:35.36 |
| Robin_Watts_ | Yesterday we had a national celebration of a bloke who tried to burn parliament to the ground. | 15:36.15 |
| kens | Still burning him in effigy. WHat do you have to do to be forgiven ? | 15:37.55 |
| Robin_Watts_ | Succeed? :) | 15:38.13 |
| kens | THat might work | 15:38.40 |
| Robin_Watts_ | He could use their expenses forms as kindling. | 15:38.57 |
| kens | THough it wasn't an unqualified success for Cromwell | 15:38.58 |
| henrys | reads about fawkes | 15:39.30 |
| Robin_Watts_ | Well, he was a papist, so he was never going be popular. It's not that we have long institutional memories in this country or anything, but the village church still puts a few pence away each year against the purchase of firewood for burning catholics. | 15:42.04 |
| kens | err, I thought that was witches | 15:42.59 |
| Robin_Watts_ | The vicar said catholics. Apparently he has been very close to pointing this out to the local catholic clergy at times :) | 15:43.41 |
| chrisl | Robin_Watts_: I think that's utterly appalling - only a few pence?!? | 15:43.48 |
| henrys | of 5 of the meeting | 15:55.41 |
| | paulgardiner:reading ... | 16:01.05 |
| paulgardiner | ok. I'm here | 16:02.05 |
| henrys | I wonder if we should post sample form stuff at the apk release site and ask folks to test them on their droid platforms. paulgardiner do you think that would be useful? | 16:04.16 |
| paulgardiner | Yes, I reckon so. We'd probably want to frequently update it, but presumably that isn't a problem. | 16:05.24 |
| henrys | is robin_watts_ managing the apk release? | 16:06.41 |
| Robin_Watts_ | I'd assumed an apk would go up as part of the release. | 16:06.47 |
| | I can do an apk build, sure. It's usually tor8 that does releases though. | 16:07.31 |
| paulgardiner | Or I can do the build, and Robin_Watts_ can upload it if that's easier | 16:08.09 |
| henrys | I think an alpha apk with some form test files would be useful. | 16:08.12 |
| | I don't think a full blown release is needed. | 16:08.37 |
| | we do want to get this in the hands of droid users right? | 16:08.51 |
| Robin_Watts_ | I thought a full release would be worthwhile to show that it works on windows/linux too. | 16:09.28 |
| paulgardiner | I'd have thought so, unless we are worried that some of the current shortcomings might put some off for good. | 16:09.39 |
| henrys | Robin_Watts_:I'd like that too, tor8? | 16:10.04 |
| paulgardiner | The linux app is probably out of date with current features | 16:10.16 |
| tor8 | my android environment is a bit old by now | 16:11.11 |
| | and I think the x11 viewer is quite far behind in terms of modifications you've done for the win32 viewer to support forms? | 16:11.41 |
| | I'd suggest just going with the .apk (and -maybe- a win32) release for this early forms demo. | 16:12.03 |
| paulgardiner | tor8: I'd imagine so. | 16:12.07 |
| henrys | I was hoping we could have a banner on the download page - "help us test forms - here are some files". that would serve the dual purpose of advertising and getting some testing? | 16:12.24 |
| tor8 | henrys: also, "upload files that don't work here, with a description of what doesn't work" or do we expect them to go through bugzilla for all that? | 16:13.17 |
| Robin_Watts_ | tor8: If you do the .zip (or the tagging), I'll do the builds. | 16:13.27 |
| henrys | right if you do have forms that don't work please go to bugzilla | 16:13.48 |
| | I didn't really have anything to say about the report - looks like good progress as usual. Anybody else? | 16:14.42 |
| Robin_Watts_ | I'll do the website banner etc too if no one else has a burning desire to do it. | 16:14.48 |
| | <blink><font="garish"><color="purple">.... | 16:15.29 |
| paulgardiner | Only thing I have to add is that there are a few commits building up on paulg/master that could do with reviewing. | 16:15.39 |
| henrys | we could make them fill out a pdf form to do the download ;-) | 16:16.12 |
| paulgardiner | :-) | 16:16.20 |
| chrisl | It might be a good idea to make it clear there are other ways to get files to us than via bugzilla - PDFs with forms in them are a bit more likely to be private/confidential. | 16:17.03 |
| halabund | Hello | 16:17.14 |
| ghostbot | what's up, halabund | 16:17.14 |
| henrys | tor8, Robin_Watts_:can you review paulgardiner's changes. | 16:17.50 |
| | I assume those changes should be in the release. | 16:18.07 |
| Robin_Watts_ | sure. I'll look now, unless tor8 is wanting to. | 16:18.09 |
| halabund | I'm looking for a tool to normalize the widths of pages. I converted a PDF from a DJVU which had pages with random widths. I simply need to rescale all pages so they have the same width relative to each other. | 16:18.53 |
| paulgardiner | Actually, I think some have been reviewed, but just haven't been pushed yet. | 16:18.56 |
| halabund | Does anyone here know of a tool that can do this? | 16:19.12 |
| Robin_Watts_ | halabund: Not me, sorry. | 16:20.01 |
| henrys | halabund:I'm not quite sure I completely understand what your asking but I'll hazard this will get you started: http://stackoverflow.com/questions/7446552/resizing-a-pdf-using-ghostscript | 16:23.28 |
| chrisl | halabund: you could try Ghostscript with pdfwrite and use the -dFIXEDMEDIA and -dPDFFitPage options. Set the media size you want | 16:23.44 |
| Robin_Watts_ | paulgardiner: http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=commitdiff;h=12da2b4d0f1fdec7051b98bc63418b4a3ea2ea79 | 16:23.49 |
| | In Java_com_artifex_mupdf_MuPDFCore_getWidgetAreasInternal should you also check for pc being NULL ? | 16:24.12 |
| | and in getPageLink | 16:24.46 |
| chrisl | henrys: I'm about to head out - it's my intention to have the gs_fapi branch pulled onto master by the end of the week, if that sounds okay. | 16:25.16 |
| Robin_Watts_ | Other than that, that one looks great. | 16:25.31 |
| henrys | chrisl:sounds great! what about boldening? | 16:25.36 |
| chrisl | henrys: it's done (at least a first pass), erm..... http://www.ghostscript.com/~chrisl/fapi_with_boldening.png | 16:26.29 |
| | FAPI image on the left again | 16:26.41 |
| henrys | awesome! | 16:26.54 |
| chrisl | It was *much* easier than I had expected - the image "munging" code is very self contained | 16:27.26 |
| paulgardiner | Robin_Watts_: I think it's okay. gotoPageInternal always sets pc non-NULL, but the record it points to may have a NULL page if the load failed. | 16:28.04 |
| Robin_Watts_ | fair enough. | 16:28.18 |
| chrisl | Right, off now - bye! | 16:28.21 |
| Robin_Watts_ | night chrisl. | 16:28.28 |
| paulgardiner | Robin_Watts_: ... although I have to admit, how it works came as a surprise to me. | 16:29.14 |
| halabund | thanks chrisl_away and henrys, I'll try that | 16:34.08 |
| Robin_Watts_ | halabund: Be aware that a gs based solution will take your PDF file completely to bits and then rebuild it. | 16:35.40 |
| | so don't expect any non-display information to make it through. | 16:36.04 |
| halabund | Robin_Watts_: it's just a scanned book. I already lost the searchability when converting from DJVU to PDF | 16:37.12 |
| | thanks for the warning though! | 16:37.18 |
| | I wish there were some usable DJVU viewers for OS X, then I wouldn't need to convert at all ... | 16:37.43 |
| henrys | I use a browser plugin djvu plugin host | 16:39.32 |
| halabund | actually I haven't tried the plugin viewer yet | 16:40.23 |
| tkamppeter | Robin_Watts_, I think Gutenprint has some raw mode, so that you can print bitmaps without redithering. Simply post on the Gutenprint mailing list and they will help you. https://lists.sourceforge.net/lists/listinfo/gimp-print-devel | 16:45.42 |
| Robin_Watts_ | tkamppeter: Thanks. | 16:49.50 |
| henrys | and another meeting ... I got nothin' | 17:01.31 |
| mvrhel | good morning | 17:02.02 |
| henrys | I'll repeat that for mvrhel's benefit: and another meeting ... I got nothin' | 17:02.08 |
| mvrhel | hehe | 17:02.16 |
| | is kens still here | 17:02.28 |
| kens | yes | 17:02.39 |
| | meeting | 17:02.42 |
| mvrhel | kens: I would think you would just want to use the ICC space that is already associated with the objects when they come to pdfwrite | 17:04.12 |
| | to answer you email question | 17:04.24 |
| | s/you/your/ | 17:04.59 |
| marcosw | sorry I'm late, did I miss the meeting? | 17:06.47 |
| henrys | no you're good | 17:07.06 |
| | I didn't have much to say, what do you have? | 17:07.19 |
| | I do sort of think we should say "good enough" to your customer and move on, but whatever you think marcosw. | 17:07.58 |
| marcosw | the latest email says they can't leave off the -IResource/Fonts option since their customers are adding fonts to the system. | 17:09.41 |
| henrys | I know I requested this before, I'd like to do submit changes to the pxlcolor device and have it cluster tested - imho if a device isn't part of the cluster the behaviour should be to generate sums for the master when the job is submitted it'll just take 2x longer. | 17:10.19 |
| marcosw | other than startup times why would reading fonts from Resource/Fonts instead of %rom%Resource be so much slower? | 17:10.31 |
| mvrhel | kens: did what I said make sense? | 17:10.48 |
| kens | one minute | 17:10.58 |
| mvrhel | sorry | 17:11.02 |
| | another email from them marcosw... | 17:11.22 |
| alexcher | marcosw: because the directoru\y is not cached. | 17:11.34 |
| henrys | alexcher how is the soft mask stuff coming? | 17:12.48 |
| alexcher | henrys: I'm still working. | 17:13.16 |
| Robin_Watts_ | henrys: bug 693415: Is this in any way related to the hpgl path mode? | 17:13.34 |
| henrys | Robin_Watts_:I don't think so. This is about HP adding another segment when filling. | 17:14.48 |
| | unless that is something expected in that model, I don't see why it would be though. | 17:15.56 |
| kens | mvrhel I can use the ICCBased space as is if I want to embed an ICCBased space in theoutput, but how (if possible) can I use that to do a conversion to a device space ? | 17:16.13 |
| Robin_Watts_ | his example looks exactly like what I'd expect in that model. | 17:16.21 |
| mvrhel | kens: that is your source space to use in the conversion. | 17:16.51 |
| kens | Hmm let me read doc again | 17:17.05 |
| mvrhel | kens: to create the link you will need a source color space and a destination color space | 17:17.27 |
| kens | mvrhel right, so the ICCbased one is then the source space ? | 17:17.48 |
| mvrhel | yes | 17:17.53 |
| | and the device profile will be used as the destination | 17:18.02 |
| kens | OK what is the cost of creating a linkn in performance terms ? | 17:18.04 |
| | I have the device profile, but I may want to change it at startup is that legal ? | 17:18.22 |
| mvrhel | kens: it is expensive. so it is cached in the link cache which is part of the imager state | 17:18.26 |
| kens | ah, so I don't need to cache it myself :-) | 17:18.37 |
| mvrhel | no | 17:18.42 |
| | and if you change the device profile, it will catch this | 17:18.57 |
| henrys | Robin_Watts_:maybe I don't understand something. My example is much simpler, HP implicitly closes that path upon PM1 when filling and doesn't when stroking. What does that have to do with counting PU's as part of a fill path? | 17:19.08 |
| kens | Oh, that's nice | 17:19.09 |
| mvrhel | kens: ideally you don't have to do a thing except ask for a link and use it | 17:19.32 |
| kens | So if I want a device colour I set up the deice profile and all is well. If I want ICCbased I havce it already, and if I want unchanged tehn I am | 17:19.37 |
| | done because I use the existing code | 17:19.49 |
| Robin_Watts_ | henrys: it's possible I'm misunderstanding. | 17:19.58 |
| mvrhel | kens: that sounds correct | 17:20.10 |
| kens | OK good. Advanced question for extra credit: How do I handle the object based colour ? | 17:20.35 |
| mvrhel | kens: is this using different destination profiles or different source profiles based upon objects? (we can do both) | 17:21.13 |
| kens | mvrhel different destination profiles basded on object type | 17:21.29 |
| henrys | Robin_Watts_:I guess it is sort of related. If the pen is down (lineto) the closepath is always added. | 17:22.00 |
| mvrhel | kens: ok. so if you have specified object profiles on the command line, it should happen invisible to you. Now, we do still have the limitation that they all have to be the same color space | 17:22.35 |
| | I need to change that | 17:22.39 |
| | kens: oh one thing | 17:22.54 |
| kens | mvrhel I see, then I will pass on this one for th emoment, and just bear it in mind | 17:22.57 |
| henrys | Robin_Watts_:I think I can patch up the path after but I'd rather not introduce more mess to the chaos. | 17:23.12 |
| mvrhel | kens: there have been a few minor changes since I wrote that note for you | 17:23.24 |
| | let me point you to some code | 17:23.32 |
| henrys | sorry the stuff about the pxlcolor device was for marcosw - I left out his name. | 17:24.06 |
| mvrhel | uhoh lost kens | 17:24.12 |
| kens | Huh network dropout | 17:24.51 |
| | I think I need a new router | 17:24.56 |
| Robin_Watts_ | henrys: We could introduce a new graphics primitive to paths (in the graphics lib), and treat that differently in fill/strokes. | 17:25.11 |
| mvrhel | kens: I am going to show you a snippet of code | 17:25.18 |
| kens | excellent, thanks | 17:25.25 |
| Robin_Watts_ | That way no need to 'fixup'. | 17:25.32 |
| henrys | Robin_Watts_:yup that would be the other alternative - I suppose you could just use the current boolean to trigger the closepath. | 17:26.10 |
| mvrhel | i really dislike the default font in windows 8.... | 17:26.29 |
| kens | Another reason to avoid it.... | 17:26.43 |
| marcosw | henrys: I saw the pxlcolor/cluster request. You should open an enhancement request and assign it to me. :-) | 17:26.49 |
| henrys | marcosw:yeah I'll make it P2 and use a customer number. | 17:27.27 |
| Robin_Watts_ | tor8: I've pushed pauls commits, so when you're happy, tag, and then you can build and/or tell me, and i'll build. | 17:27.40 |
| henrys | Nate Silver now has Obama at 90% chance to win. | 17:28.49 |
| Robin_Watts_ | Didn't he have him at 97% earlier? | 17:29.05 |
| kens | Who is Nate Silver ? | 17:29.16 |
| Robin_Watts_ | http://politics.slashdot.org/story/12/11/05/1410233/nate-silvers-numbers-indicate-probable-obama-win-world-agrees | 17:29.55 |
| marcosw | alexcher (et.al.): is there way to construct a Fontmap file and use a combination of -I%rom%Resource and -IResource/Fonts options on the command line so that the compiled in fonts are used preferentially? BTW, -I%rom%Resource fails in 8.64, but I assume there is a patch that I'll be able to find since it works in 9.00. | 17:30.06 |
| henrys | I follow his blog: http://fivethirtyeight.blogs.nytimes.com/ | 17:30.52 |
| kens | aha | 17:30.59 |
| mvrhel | kens: so if you look in gxcmap.c around line 1238 you can see that you will want to get the rendering intent structure filled up | 17:31.20 |
| | one of those will identify the object type | 17:31.35 |
| | so that the icc code will grab the correct profile for that object | 17:31.51 |
| henrys | I am reading his new book signal and the noise - quite good. | 17:31.53 |
| kens | mvrhel OK I see that | 17:32.11 |
| mvrhel | oh I like that title | 17:32.12 |
| alexcher | marcosw: AFAIK the file systems are searched in their order in the list. | 17:32.24 |
| mvrhel | kens: so that changed since I wrote you the earlier note | 17:32.30 |
| kens | OK not to worry, I have plenty to keep me busy until the staff meeting I think :-) | 17:32.54 |
| Robin_Watts_ | mvrhel: Yell when you want to talk about ETS. | 17:33.19 |
| mvrhel | kens: ok. and I still need to make the type 2 profiles | 17:33.20 |
| kens | version 2 ? Yes, that would be good. | 17:33.33 |
| mvrhel | version 2 | 17:33.38 |
| | yes | 17:33.40 |
| kens | For now I intend to keep the old code and allow it as a fallback, like the UseFastCOlor stuff | 17:33.49 |
| mvrhel | kens | 17:34.01 |
| | one thing that is cool | 17:34.05 |
| | is that you can use the same logic to do the old conversions | 17:34.22 |
| | that is with getting a link etc | 17:34.27 |
| alexcher | marcosw: -I pushes the directories to the list. We need either rebuild the whole list or add an append option. | 17:34.34 |
| kens | mvrhel I want to throw the old code away as soon as I can | 17:34.45 |
| mvrhel | by setting rendering_params.cmm = gsCMM_NONE | 17:35.01 |
| | then, you still apply the link | 17:35.07 |
| | but it will do old style conversions | 17:35.12 |
| kens | Hmm, but not the old pdfwrite conversions ;-) | 17:35.22 |
| mvrhel | how are those different? | 17:35.45 |
| | we can add another cmm type for that... | 17:36.04 |
| kens | Well partly its the fact that device space conversions use the PLRM method, but its all code in pdfwrite, not the kernel | 17:36.16 |
| | And partly its the hideous mess that is the logic in pdfwrite at the moment | 17:36.38 |
| ray_laptop | marcosw: you may be able to get the performance of %%rom by having BOTH -I%%romesource/Font AND -IResource/Font it generally will find the stuff in the %%rom. | 17:36.39 |
| mvrhel | oh. well you could throw that out and just always use the CMM | 17:36.51 |
| kens | mvrhel I don't wnat to keep the old code or method at all, I want to move over completely to the CMS | 17:36.59 |
| mvrhel | and you would have PLRM and ICC | 17:37.01 |
| kens | Indeed. | 17:37.07 |
| mvrhel | kens: ok sounds good | 17:37.12 |
| ray_laptop | marcosw: Also you may want to have them specify -sGenericResourceDir=%%rom/Resource/ | 17:37.13 |
| kens | THat is exactly what I want, but all done 'properly' | 17:37.21 |
| mvrhel | right | 17:37.27 |
| kens | mvrhel what is there right now for pdfwrite is obscure and horribly coded | 17:37.38 |
| | It will be much better when I am done (I hope!) | 17:37.54 |
| alexcher | marcosw: How many failed searches their files generate? | 17:37.55 |
| mvrhel | kens: right. I tried to follow the logic in there before | 17:38.01 |
| kens | :-) | 17:38.13 |
| mvrhel | Robin_Watts_: give me 15 minutes before we start ETS ok. brb | 17:38.17 |
| Robin_Watts_ | ok. | 17:38.24 |
| kens | OK thanks mvrhel I have a direction for tomorrow now | 17:38.36 |
| | TIMe for me to go though goodnight all | 17:38.44 |
| marcosw | alexcher: I'm not sure I understand your question? Are you asking how many fonts are they using? It's three. | 17:38.48 |
| henrys | we should wrap up the meeting, ray_laptop:hope the kids get better! | 17:39.12 |
| | soon | 17:39.13 |
| ray_laptop | henrys: thanks | 17:39.29 |
| marcosw | Robin_Watts_: are you the person to complain about the search function on git.ghostscript.com? | 17:39.33 |
| Robin_Watts_ | marcosw: I don't believe so. | 17:39.47 |
| alexcher | marcosw: If the font cannot be found, multiple copies of the directory on the search path will be searched. | 17:40.06 |
| | marcosw: How important unsuccessful resource searches? | 17:41.20 |
| marcosw | alexcher: I'm not sure if I'm just being dense today but I don't understand what that means either. | 17:42.41 |
| alexcher | marcosw: gs cannot remove directories from the search path. | 17:44.28 |
| marcosw | alexcher: let me summarize the problem: there is a significant difference in 8.54 vs 8.64 performance with the customers file. | 17:45.27 |
| alexcher | marcosw: what does the profiler say? | 17:46.05 |
| marcosw | If I remove the font directory from the -I command line option than 8.64 is nearly as fast as 8.54, but the customer has users who are installing their own fonts so needs the -I option to find these additional fonts. | 17:46.41 |
| ray_laptop | marcosw: I just put my suggestions in an email (in case they were hard to decipher here). | 17:47.12 |
| marcosw | Furthermore 8.54 is compiled with COMPILE_INITS=0, so is loading fonts from disk. I suppose I could try compiling 8.64 with COMPILE_INITS=0 and see if that makes its performance better. Seems counterintuitive but nothing about this problem makes sense. | 17:48.16 |
| ray_laptop | having the -I%rom%Resource/Font BEFORE the -IResource/Font should only look on the disk if it can't find the font in the %rom% file system | 17:48.20 |
| alexcher | marcosw: let's find the exact revision that's slow. | 17:48.26 |
| marcosw | I've done that, let me find the commit hash | 17:48.42 |
| henrys | bbiaw | 17:49.37 |
| marcosw | 7a31db6d4142087d29c17e875ef2de1727b9f8b2 is fast | 17:49.41 |
| | 62b66eb67bda44d5becebc709b565d45bf70c585 is slow | 17:49.49 |
| | there is a rev between them but it doesn't compile/run | 17:50.00 |
| alexcher | marcosw: Yow fast is the current version with COMPILE_INITS=0 ? | 17:54.18 |
| marcosw | alexcher: haven't tried that yet. Running that test now. | 17:54.48 |
| alexcher | marcosw: How fast is the current version with COMPILE_INITS=0 ? | 17:54.49 |
| | marcosw: It's a big commit. Is there a bug report to thack the findings? | 17:55.49 |
| marcosw | alexcher: http://bugs.ghostscript.com/show_bug.cgi?id=693387 | 17:56.21 |
| mvrhel | Robin_Watts_: I am back. let me get the ETS project on my desktop | 17:59.19 |
| alexcher | marcosw: Where's the sample file? | 17:59.33 |
| marcosw | oops, i'll attach it now. | 17:59.46 |
| ray_laptop | the 34f0b7f06 commit just moved files from 'lib/' to Resource/Init | 17:59.56 |
| alexcher | marcosw: I'll try to reproduce the problem on Linux. | 18:01.10 |
| Robin_Watts_ | mvrhel: ok. how do you want to do this - shall we walk through the C version? | 18:01.32 |
| mvrhel | Robin_Watts_: yes that sounds fine | 18:01.51 |
| | hold on though | 18:02.00 |
| marcosw | ray_laptop: yup, and increased the run time significantly. From 27 seconds to 83 seconds for the first 1000 pages of the customer's file. | 18:02.15 |
| ray_laptop | marcosw: are those timings with COMPILE_INITS=0 ? | 18:03.11 |
| marcosw | they are with the default options. (i.e. ./autogen.sh ; make ) | 18:03.33 |
| ray_laptop | marcosw: do you know what the defaults were back then ? | 18:04.10 |
| ray_laptop | goes to look at the logs for when we made COMPILE_INITS=1 the default | 18:04.29 |
| marcosw | other than 8.54 had compile_inits=0 and 8.64 =1 no. | 18:04.42 |
| | ray_laptop: it may well have changed with the directory reorg that you did. | 18:05.15 |
| mvrhel | Robin_Watts_: ok got project and built in VS 2012... | 18:05.40 |
| Robin_Watts_ | ok. | 18:05.52 |
| | So test_evenbetter.c has been expanded a bit to have some more flags etc and to cope with pams as well as pgms. | 18:06.16 |
| mvrhel | yes. I see that. that is nicew | 18:06.29 |
| Robin_Watts_ | but there is nothing earthshaking in there. | 18:06.32 |
| ray_laptop | marcosw: the reason that 34f0b7f06 didn't run is that I missed a file in the 'mv' (pdf_draw.ps) | 18:06.50 |
| Robin_Watts_ | Do you want to start with even_better_new, or with the actual core loop even_better_line_hi ? | 18:07.44 |
| mvrhel | lets go in to the new | 18:08.46 |
| | that wont take long | 18:09.01 |
| | so the even_ehi and even_elo parameters | 18:09.39 |
| Robin_Watts_ | ok. First 'interesting' thing in here I reckon is the even_ehi and even_elo... | 18:09.42 |
| | :) | 18:09.44 |
| mvrhel | yes exactly | 18:09.55 |
| Robin_Watts_ | Firstly, why do they have 'even' in their names? Isn't that implied? | 18:10.00 |
| | Essentially, I think this corresponds to the mention of 0.55 in the paper. | 18:10.17 |
| | In section 6. | 18:10.32 |
| mvrhel | that was what I was wondering. So it is a empirical fudge factor | 18:10.43 |
| | hold on let me open the paper | 18:10.54 |
| Robin_Watts_ | 'We address this by clamping the error and threshold modulation to. +/-0.55 of one quantization level." | 18:11.16 |
| | yeah, it seems a pretty arbitrary fudge to me. | 18:11.25 |
| | As such I vaguely feel that we should expose that to the user. | 18:11.43 |
| mvrhel | I agree | 18:11.54 |
| Robin_Watts_ | ok. | 18:12.09 |
| | eb_style and r_style are mine. | 18:12.24 |
| | You'll see what they are about in a mo. | 18:12.39 |
| mvrhel | ok what is the do_shadows? | 18:12.48 |
| | strengths is obviously the correlation between planes | 18:13.12 |
| Robin_Watts_ | yeah, strengths is the correlation between planes. | 18:13.24 |
| | Ignore do_shadows for now, because it's not in the vanilla C version. | 18:13.39 |
| ray_laptop | do_shadows is described in the README (and doesn't work) | 18:13.41 |
| mvrhel | is does come in eb_compute_randshift | 18:14.44 |
| | and even_better_line_rll | 18:15.03 |
| marcosw | ray_laptop and alexcher: thanks for your suggestions and help. I'll update the bug with the information that I've found regarding 8.64 and compile_inits options. I'll add both of you the bug cc list as well. | 18:15.13 |
| Robin_Watts_ | even_better_line_rll either calls out to blah_hi or blah_both, right? | 18:15.46 |
| mvrhel | yes | 18:16.06 |
| Robin_Watts_ | blah_both does not work. It's all commented out with a big #if 0. If we change that to a #if 1 it doesn't compile. | 18:16.07 |
| mvrhel | ah ok | 18:16.14 |
| | so lets move on from that. | 18:16.21 |
| Robin_Watts_ | Hence, for now, ignore do_shadows - we can try to reconstruct what it does later. | 18:16.27 |
| mvrhel | maybe a comment for now that it is disabled | 18:16.41 |
| | or not used | 18:16.44 |
| | or not working | 18:16.47 |
| Robin_Watts_ | even_better_plane_new gets called for each plane, then it sets up the 'tm' stuff. | 18:17.04 |
| ray_laptop | AIUI, do_shadows is _supposed_ to make the extra dot_distribution pass when there are only a few white dots, to make the white dots more evenly distributed and "eliminate" worms or other problems. But since individual white dots are rarely visible (except on the screen) we really don't need do_shadows | 18:17.10 |
| Robin_Watts_ | tm is one of the 2 built in styles of generating random noise. Ignore it for now. | 18:17.30 |
| ray_laptop | I think we (RobinWatts) should just rip it out | 18:17.39 |
| Robin_Watts_ | ray_laptop: I'm not averse to that idea, but I'd like to understand it a bit better first - I don't think it's hugely hard to resurrect. | 18:18.22 |
| mvrhel | yes. lets just make a comment on it and move on for now | 18:18.35 |
| Robin_Watts_ | mvrhel: Do you want to look at even_better_plane_new ? | 18:18.43 |
| mvrhel | Robin_Watts_: yes lets go in there for a sec | 18:18.56 |
| Robin_Watts_ | OK. log2_levels is obvious enough. (levels = 2 for a black and white image or higher if we have multiple sizes of ink droplet available to us) | 18:20.00 |
| mvrhel | ok. this is getting the randome stuff set up | 18:20.04 |
| Robin_Watts_ | The even_c1 is a magic constant used to effect the shifts which certain tables are stored with. | 18:20.44 |
| mvrhel | ah ok | 18:20.59 |
| | I was wondering about the log of the aspect. Is this the aspect ratio | 18:21.19 |
| Robin_Watts_ | and the even_rlimit is a limit used later on to check that the error hasn't overflowed the bounds where it will cause calculations to go wrong. | 18:21.36 |
| | Yes. | 18:21.38 |
| | So, the first for loop sets up a table that maps from input value to 'amount of ink' in the plane. | 18:22.43 |
| mvrhel | ugh. I need to get rock and scroll installed to vs2012 | 18:22.47 |
| Robin_Watts_ | For pams and pgms, FF = white, so the code here calulates a scaled version in nli, and then puts 65536-nli into the table. | 18:24.03 |
| mvrhel | Robin_Watts_: ok. that makes sense. How does he adjust for ink amounts for the different dots? | 18:24.21 |
| | is that done here? | 18:24.31 |
| Robin_Watts_ | so white comes out as 0, and full ink coverage comes out as 65536. | 18:24.33 |
| | I'm not sure what you mean, but I am fairly sure the answer is no :) | 18:25.03 |
| mvrhel | "maps from input value to 'amount of ink' in the plane." are we just talking about a gamma correction? | 18:25.41 |
| | and there is some random term going on in here... | 18:26.02 |
| Robin_Watts_ | mvrhel: Ah, right. | 18:26.18 |
| | The code can take an input 'lut' table. (Confusingly he reuses names) | 18:26.39 |
| | IF supplied, then that is assumed to map input values to 24bit fixed point values. | 18:27.10 |
| | So if you want to do gamma correction, you supply a lut with the required curve in for each plane. | 18:27.28 |
| | If you don't supply such a lut (see "if (lut == NULL)") then he assumes a linear mapping. | 18:27.53 |
| mvrhel | ok. So I guess I am still not clear what is getting set up in even_better_plane_new | 18:27.57 |
| Robin_Watts_ | That was just the first for loop. | 18:28.10 |
| mvrhel | ok. I am not clear in the first for loop... :) | 18:28.25 |
| | oh that is the gamma | 18:28.39 |
| | but linear if not supplied | 18:28.50 |
| | right? | 18:28.52 |
| Robin_Watts_ | Yes. | 18:28.55 |
| | with an inbuilt 'inversion' from 'amount of light' to 'amount of ink'. | 18:29.08 |
| mvrhel | ok. sorry for being slow... | 18:29.10 |
| | gotcha. a comment here would be nice | 18:29.24 |
| Robin_Watts_ | No problem at all. It took me all last week staring at this code. | 18:29.26 |
| | mvrhel: That is true of pretty much everywhere in this code :( | 18:29.38 |
| | Ok, so the next for loop... That sets up 2 more luts. rb_lut and rs_lut. | 18:30.11 |
| mvrhel | ok. Robin_Watts_ are you doing that then? | 18:30.12 |
| Robin_Watts_ | I will do, sure. | 18:30.21 |
| mvrhel | ok | 18:30.24 |
| | ok next loop | 18:30.35 |
| | which could clearly use a comment... | 18:30.52 |
| | as you said it is setting up rb_lut and rs_lut | 18:31.44 |
| | looks like these are used in the distance calculation | 18:33.01 |
| Robin_Watts_ | Right, comment writted. | 18:33.09 |
| | rb_lut is the EvilToadScreaming distance bias amount. | 18:33.36 |
| mvrhel | hehe | 18:33.45 |
| Robin_Watts_ | or rather, it's the 'expected distance between dots for a given ink level'. | 18:34.04 |
| mvrhel | now that is an interesting value | 18:34.24 |
| | and this is where some randomness is introduced | 18:35.52 |
| | I would think that the dot size would be important somewhere here | 18:36.08 |
| Robin_Watts_ | careful. | 18:36.28 |
| | The code is confusing here as he's conflated 2 independent loops. | 18:36.40 |
| | rb_lut is the expected distance value. | 18:36.53 |
| mvrhel | I see and I don't see any random stuff except in the names | 18:37.03 |
| Robin_Watts_ | rs_lut is the scale factor for the random noise. | 18:37.13 |
| mvrhel | ah ok | 18:37.19 |
| | gotcha | 18:37.24 |
| Robin_Watts_ | hence no actual random stuff in here. | 18:37.29 |
| | and rb_lut is completely independent of the rand_scale stuff. | 18:37.46 |
| | Then we create the line buffers, and initialise them with sane values. | 18:38.20 |
| mvrhel | right | 18:38.35 |
| | ok. so with a few comments I think we are ok | 18:38.46 |
| | I am still fuzzy though | 18:39.01 |
| Robin_Watts_ | OK, so let's move on to... even_better_line | 18:39.10 |
| mvrhel | about how dot size would come into play here | 18:39.12 |
| | one quick thing | 18:39.36 |
| | about rb_lut | 18:39.37 |
| Robin_Watts_ | As I understand it, dot size isn't considered at all. | 18:39.51 |
| mvrhel | wouldn't that be important in the expected distance? | 18:40.14 |
| | or at least weighting the error? | 18:40.38 |
| | anyway I will not worry about that now | 18:40.45 |
| Robin_Watts_ | mvrhel: Yes. | 18:40.45 |
| mvrhel | we can move on | 18:40.55 |
| | even_better_line | 18:41.11 |
| Robin_Watts_ | You'd expect the calculation of rb_lut to take into consideration the number of levels around. | 18:41.27 |
| mvrhel | right | 18:41.36 |
| | maybe a comment about that here would be good | 18:41.47 |
| Robin_Watts_ | but I don't believe he does. (I've been working with levels=2 for now, so not been worrying about that). | 18:42.04 |
| mvrhel | right. we can worry about multilevel stuff later | 18:42.37 |
| | so we really need to push into even_better_compress_rll | 18:43.25 |
| Robin_Watts_ | Ok, so even_better_line | 18:43.28 |
| | Well, yes and no. | 18:43.36 |
| | Let's take a high level view to start with. | 18:43.43 |
| mvrhel | ok | 18:43.47 |
| Robin_Watts_ | When he originally wrote this code, I think he wrote it without the runlength encoding crap. | 18:44.02 |
| mvrhel | oh I see | 18:44.09 |
| Robin_Watts_ | and he added that to allow people to change the width as they dithered. | 18:44.29 |
| | (You can generate a 1000 pixel wide image and then scale it up to 2500 or something). | 18:44.59 |
| | 1) This seems like a bonkers thing to do to me. | 18:45.13 |
| | 2) This seems like a bonkers thing to do to me. | 18:45.21 |
| mvrhel | yes. I have to agree with you | 18:45.29 |
| Robin_Watts_ | I know that technically that's only 1 objection, but it's such a big one, I thought it was worth stating twice. | 18:45.39 |
| mvrhel | well hold on one sec | 18:45.49 |
| ray_laptop | Robin_Watts_: not entirely -- since each input pixel gets dithered with several dots on paper, you may not really ever need the full resolution contone | 18:46.33 |
| mvrhel | are you saying that this is used for the case where I have a NxN contone image and want to HT it to MN by MN? | 18:46.38 |
| Robin_Watts_ | Yes. | 18:46.48 |
| mvrhel | that is ok | 18:46.51 |
| | and very common | 18:46.53 |
| Robin_Watts_ | I'm not saying that scaling is a bad idea. | 18:46.58 |
| | I'm saying that scaling using run length encoding is bonkers. | 18:47.09 |
| mvrhel | that I agree with | 18:47.15 |
| ray_laptop | it's sort of the inverse of limiting image interpolation to NxN device pixels | 18:47.23 |
| mvrhel | So is the rll there just so that the output is run length encoded? | 18:47.55 |
| Robin_Watts_ | when I first saw it, I thought "ah, I bet he's gaining something by having runlengths to work with - generating multiple pixels at once or something". | 18:47.57 |
| | but no, he gains nothing from it except complexity. | 18:48.07 |
| ray_laptop | Robin_Watts_: I also misunderstood you (that run length was your objection) | 18:48.12 |
| mvrhel | he has run lengths as input? | 18:48.13 |
| Robin_Watts_ | And he has no scope in the code for scaling vertically either. | 18:48.22 |
| | mvrhel: No. The input to even_better_line is not run length coded. | 18:48.42 |
| | So he calls even_better_compress_rll to runlength encode it. | 18:48.57 |
| mvrhel | he is compressing the input? | 18:49.16 |
| Robin_Watts_ | Yes. | 18:49.28 |
| mvrhel | ugh | 18:49.31 |
| Robin_Watts_ | Yes. | 18:49.35 |
| | And then guess what he does in even_better_line_rll ? :) | 18:49.52 |
| mvrhel | ok. that is only going to lead to confusion and headaches | 18:49.52 |
| | uncompress it | 18:50.04 |
| Robin_Watts_ | yes! | 18:50.08 |
| mvrhel | ok. that should be removed | 18:50.19 |
| Robin_Watts_ | I reckon so. UNLESS of course the SSE or VEC code makes use of it - but I don't see how. | 18:50.51 |
| mvrhel | That would be impressive | 18:51.13 |
| Robin_Watts_ | I have been reluctant to hack and slay too much through this code until I'd talked it through with you. | 18:51.16 |
| mvrhel | but I can't imagine coding something like that, much less maintaining it | 18:51.29 |
| Robin_Watts_ | but yes, I'd favour stripping it back to something we understand. | 18:51.31 |
| ray_laptop | at one point Raph had a rendering lib that he developed that rendered to RLL instead of a bitmap. He probably developed the ETS using the output from that graphics lib | 18:51.42 |
| mvrhel | Robin_Watts_: ok so on to even_better_line_rll? | 18:52.59 |
| Robin_Watts_ | sorry, phone went. | 18:53.18 |
| | yeah, onto that. | 18:53.24 |
| ray_laptop | so he probably added the 'compress' code later to accept uncompressed input | 18:53.40 |
| Robin_Watts_ | and immediately onto even_better_line_hi | 18:53.41 |
| mvrhel | Robin_Watts_: right | 18:53.51 |
| | this is the main working function | 18:54.13 |
| Robin_Watts_ | It is. | 18:54.17 |
| | Ignore all the variable defs, we'll deal with 'em as we come to them. | 18:54.31 |
| | So, I added a comment to explain the variables we keep around. | 18:54.55 |
| | and the first little for loop just sets the initial conditions. | 18:55.41 |
| mvrhel | yes. ok. | 18:55.54 |
| Robin_Watts_ | The coupling stuff; this is the multiplane optimisations. | 18:56.09 |
| | He has 2 versions in here. The one described in the paper, plus a modified version 'FANCY_COUPLING'. I don't claim to entirely understand FANCY_COUPLING. | 18:56.49 |
| mvrhel | ok only used if FANCY_COUPLING | 18:56.52 |
| | hey its fancy | 18:57.09 |
| Robin_Watts_ | No, coupling is used both with and without FANCY_COUPLING. | 18:57.25 |
| mvrhel | what more do you need to know about it | 18:57.26 |
| | ok | 18:57.31 |
| Robin_Watts_ | yeah :) | 18:57.34 |
| | So, our outer loop is for i from 0 to xd. | 18:58.07 |
| mvrhel | right | 18:58.12 |
| Robin_Watts_ | So i is the output pixel. | 18:58.13 |
| | He does some wacky stuff that had me confused for ages to try and skip multiple blank pixels. | 18:58.41 |
| | and I'm sure it's very clever. | 18:58.45 |
| | and I'm fairly sure it doesn't work. | 18:58.52 |
| mvrhel | oh that is the comment around 848 | 18:59.17 |
| Robin_Watts_ | I am tempted to say we should ignore it and skip over it for now. | 18:59.22 |
| | yes. | 18:59.42 |
| | oh, god. | 19:00.18 |
| mvrhel | Robin_Watts_: yes you are probably correct about white | 19:00.28 |
| Robin_Watts_ | I think I've spotted the flaw in my understanding. | 19:00.33 |
| | but even so I'm still suspicious. Let's skip it and come back to it later. | 19:00.55 |
| | So line 901. | 19:01.11 |
| mvrhel | Robin_Watts_: so right now, you have this disabled | 19:01.15 |
| | with n_work | 19:01.23 |
| Robin_Watts_ | mvrhel: No, it's enabled. | 19:01.28 |
| mvrhel | oh ok | 19:01.38 |
| | I see | 19:01.41 |
| Robin_Watts_ | I am just suspicious that it's never firing. (or not firing often enough). | 19:01.59 |
| mvrhel | oh n_work is locally defined and used outside the loop | 19:02.12 |
| Robin_Watts_ | n_work is defined to be 0, then increments by 1 for each plane that has a non-zero pixel in it. | 19:02.38 |
| mvrhel | oh never mind | 19:02.39 |
| Robin_Watts_ | If n_work ends up being 0, then we can skip all the hard work. | 19:02.52 |
| mvrhel | right | 19:03.09 |
| | ok line 901 | 19:03.16 |
| Robin_Watts_ | The top loop basically checked to see if the next 'jmax' pixels were all white, and if not, we come through here. | 19:03.53 |
| mvrhel | right | 19:04.02 |
| Robin_Watts_ | jmax = 16, or the number of pixels left to do if less than 16. | 19:04.08 |
| | So the contents of these loops can be thought of as being "for each pixel in each plane..." | 19:04.41 |
| | count is the number of pixels left in the current run. It's initially zero, so we start by runlength decoding the first runlength entry to get src_pixel. | 19:05.40 |
| mvrhel | Robin_Watts_: so jmax is the loop across the planes? | 19:05.41 |
| Robin_Watts_ | No. for j = 0 to jmax is the loop across output pixels. | 19:06.11 |
| mvrhel | or a loop across 16 pixels | 19:06.15 |
| Robin_Watts_ | yes. | 19:06.19 |
| mvrhel | ah | 19:06.19 |
| | ok | 19:06.20 |
| | a comment there would be nice | 19:06.49 |
| Robin_Watts_ | Any comment I put there will depend on my understanding of the earlier skipping code. | 19:07.21 |
| | but yes. | 19:07.34 |
| mvrhel | well at minimum a note that it is running across output indices | 19:08.12 |
| | now work_idx is running across non-white planes | 19:08.31 |
| Robin_Watts_ | So, for each src_pixel we read, we lookup in our luts, to get: iml (the image level), rbl (the expected distance) | 19:08.31 |
| | yes. | 19:08.45 |
| | and rs (the random noise shift level) | 19:09.06 |
| mvrhel | Robin_Watts_: right | 19:09.33 |
| Robin_Watts_ | count-- <- that's one pixel from this runlength run done. | 19:09.53 |
| | So we're into the real routine now. | 19:09.59 |
| mvrhel | if (count[plane_idx] == 0) | 19:10.00 |
| | the comment about that | 19:10.21 |
| Robin_Watts_ | That's the runlength decode. Go on. | 19:10.28 |
| mvrhel | so why does it not get the lut stuff if if (count[plane_idx] !=0) | 19:11.30 |
| | I am confused by the comment vs. the code | 19:11.44 |
| Robin_Watts_ | mvrhel: The first time we enter this routine, count = 0, so we read the next token. | 19:11.45 |
| | That sets count to be the length of the run. | 19:12.06 |
| | and we decrement that by 1 each time around the loop. | 19:12.15 |
| | "Decode the next runlength entry if required." <- it's required if count == 0. | 19:13.01 |
| | Otherwise we know that we decoded it last time around, and the iml, rbl, rs values are all still valid. | 19:13.23 |
| mvrhel | oh ok | 19:13.31 |
| Robin_Watts_ | Ok, so the next bit of code is for equation 2 from the paper. | 19:14.18 |
| | That's obvious enough I think? | 19:14.28 |
| mvrhel | yes. a pretty good match actually | 19:14.56 |
| Robin_Watts_ | Then we get the guts of ets. | 19:15.09 |
| mvrhel | other than pr is not clear to me | 19:15.16 |
| | but I can assume that is r'' | 19:15.29 |
| Robin_Watts_ | Raph uses 'p' to mean 'pointer to' I think. | 19:15.43 |
| mvrhel | I did not like the use of '' in the paper | 19:16.12 |
| Robin_Watts_ | so 'pr[i]' = the r value for i. | 19:16.16 |
| | Me either. | 19:16.18 |
| | It was just wrong. | 19:16.24 |
| mvrhel | ok. so I agree that is equation 2 | 19:16.49 |
| | the forward error | 19:16.53 |
| Robin_Watts_ | The forward distance. | 19:17.03 |
| mvrhel | yes distance I mean | 19:17.09 |
| Robin_Watts_ | right. | 19:17.15 |
| | So, if the pixel is white, the expected distance is infinite. | 19:18.26 |
| mvrhel | now I do agree that the test for the white pixel matches the case where g is zero in (5) | 19:18.31 |
| Robin_Watts_ | OK. so into the second part of that if. | 19:18.47 |
| mvrhel | yes. this looks like where the fun really starts | 19:19.02 |
| Robin_Watts_ | new_r = the current calculated distance. | 19:19.11 |
| | and just in case it's too huge, clip that to rlimit. | 19:19.25 |
| | (Would you be happy with me removing the even_ prefixes from these things?) | 19:19.48 |
| mvrhel | and where was even_rlimit set? | 19:19.52 |
| Robin_Watts_ | in _new | 19:19.56 |
| mvrhel | thats right | 19:20.00 |
| | Robin_Watts_: yes | 19:20.07 |
| Robin_Watts_ | cool. | 19:20.11 |
| mvrhel | when I see even I exepect to see an odd someplace... | 19:20.21 |
| Robin_Watts_ | So the paper says "and use the difference between the actual and estimate distance as the threshold modulation term" | 19:20.46 |
| | yeah, me too. drives me bonkers. | 19:20.57 |
| | but that seems a bit vague to me. | 19:21.09 |
| mvrhel | Robin_Watts_: yes. I was confused when I read that | 19:21.20 |
| | that says that if I have a great estimate, then I don't adjust the threashold | 19:21.46 |
| Robin_Watts_ | rg = new_r converted to the same fixed point representation as the rbl values. | 19:21.49 |
| mvrhel | is that due to the fact that the estimate is already built in | 19:22.06 |
| Robin_Watts_ | sorry? | 19:22.18 |
| mvrhel | and so we are simply adjusting for any error that we had in a previous calculation | 19:22.23 |
| Robin_Watts_ | No. | 19:22.29 |
| | The idea here, is that if the current ink level suggests I should have a pixel set every 10th pixel, and I'm 40 pixels away from the nearest one, I'm overdue a dot. | 19:23.50 |
| | So it biases us towards having a dot. | 19:24.00 |
| | And if the current ink level suggests that I should have a pixel set every 10th pixel, and I'm only 3 away from the last one, I should probably bias us away from having a dot. | 19:24.38 |
| | So rg = The measured distance from the last dot. | 19:25.15 |
| | rbl = The actual distance from the last dot. | 19:25.31 |
| mvrhel | ok. I guess I am confused by the wording "estimate distance " | 19:25.51 |
| | I understand what you said | 19:25.55 |
| | but not "estimate distance" | 19:26.05 |
| Robin_Watts_ | For estimate distance read "expected distance" | 19:26.20 |
| | "Thus, we estimate the average inter-dot distance, and use the difference between the actual and estimated distance as the threshold modulation term." | 19:27.14 |
| mvrhel | ok. I do like expected distance with what you said | 19:27.18 |
| Robin_Watts_ | I reckon that could be more helpfully put as: | 19:27.27 |
| | "Thus, we calculate the expected inter-dot distance, and use the difference between the actual and expected distance as the threshold modulation term." | 19:27.52 |
| mvrhel | yes. that to me is much clearer. estimated has a certain meaning to me | 19:28.07 |
| Robin_Watts_ | yeah. | 19:28.13 |
| | So then we get to a bit of the code where I've been fiddling. | 19:28.27 |
| mvrhel | implying that at some point I did something to compute it | 19:28.31 |
| | ok so r_tmp | 19:28.48 |
| Robin_Watts_ | r_tmp is 'munged' a bit here, then stored back into r_scratch | 19:28.56 |
| | The paper gives no hint at all as to what this munging is about. | 19:29.14 |
| mvrhel | I like your comments :) | 19:29.17 |
| | and what you did here for testing | 19:29.44 |
| | and this is where the paper is not clear | 19:30.03 |
| | I have trouble relating equation 5 to the distance terms | 19:30.20 |
| Robin_Watts_ | yeah. So I reckon we move on for now, and come back later when we want to experiment a bit. | 19:30.21 |
| | Most of equation 5 is in _new. | 19:30.38 |
| | rbl[g] = 0.95/(g^2) | 19:31.14 |
| mvrhel | ok. so in any event r_scratch contains r_tmp | 19:31.14 |
| | where is that? | 19:31.43 |
| Robin_Watts_ | That calculation is done in _new. | 19:31.58 |
| | eb_compute_rbscale returns 0.95 (for square aspect ratios) | 19:32.53 |
| | so rbscale = 0.95 in _new | 19:33.13 |
| mvrhel | ok I see | 19:33.26 |
| | ok back to where we were | 19:33.34 |
| Robin_Watts_ | actually, I read that as 0.95/g | 19:33.49 |
| | not g^2. | 19:33.53 |
| | but anyway, back to where we were. | 19:35.02 |
| mvrhel | you mean in rb = (rbscale * (1 << (2 * EVEN_SHIFT - even_c1))) / nl; | 19:35.07 |
| Robin_Watts_ | yeah. | 19:35.13 |
| mvrhel | is there some log aspect to this? | 19:35.23 |
| | I dont guess so | 19:35.42 |
| | I would have to look at this | 19:35.47 |
| | maybe add a comment to come back | 19:36.01 |
| | ok so we are on /* Dither each plane. */ | 19:36.43 |
| Robin_Watts_ | Yes. | 19:36.51 |
| mvrhel | with r_scratch as our threshold? | 19:37.03 |
| Robin_Watts_ | Note that we have calculated r_scratch for each plane at this point. | 19:37.13 |
| mvrhel | or no that is the biase | 19:37.17 |
| | on the error | 19:37.27 |
| Robin_Watts_ | We'll get to the error in a mo. | 19:37.33 |
| mvrhel | ok so again we are looping over the nonzero planes | 19:37.52 |
| Robin_Watts_ | Right. And for each plane we are holding the error values from surrounding pixels in e_1_1, e_m1_1 etc | 19:38.11 |
| | e_m1_1 is the one above and to the right. | 19:38.27 |
| | So the first thing we do is shuffle all those errors along to the left by one, and read the next one from the line store (piir) | 19:39.04 |
| mvrhel | ok and there are the FS weight | 19:39.13 |
| Robin_Watts_ | Indeed. | 19:39.17 |
| | Now, when I came to this code, Raph had those weights wrong. | 19:39.28 |
| mvrhel | oh really | 19:39.55 |
| Robin_Watts_ | he had the 3 and 1 reversed. | 19:39.57 |
| mvrhel | oops | 19:40.02 |
| Robin_Watts_ | Not a huge difference, but it might be worth someone double checking me there. | 19:40.34 |
| mvrhel | ok | 19:40.45 |
| Robin_Watts_ | just in case I've got it wrong. | 19:40.48 |
| | (or quite possibly, that I've made 2 changes that cancel each other out or something) | 19:41.04 |
| | So he adds in the weights and new_e_1_0 is the total error passed into this pixel from the surrounding pixels. | 19:41.43 |
| | ok? | 19:43.21 |
| mvrhel | right. this is a little different than I have usually seen this coded. usually. I see an error buffer that is for the next line with all the contributions form the previous line but I understand | 19:43.53 |
| Robin_Watts_ | He has it hardwired here so that white pixels always stay white. I can't help feeling that if we're doing that, we should set the error to 0. | 19:44.02 |
| | Yes, me too. | 19:44.06 |
| mvrhel | Robin_Watts_: I agree with you comment about the white pixel | 19:44.34 |
| | something should occur error wise | 19:44.48 |
| | i.e. no error | 19:45.00 |
| | or some adjustment | 19:45.17 |
| Robin_Watts_ | His way is quite smart in that he's not reading repeatedly from the line buffer, but it does have the potential to accumulate errors. | 19:45.18 |
| mvrhel | right. I believe one has to be much more careful when doing it this way (or rather is is easier to goof up) | 19:46.09 |
| Robin_Watts_ | (i.e. when I've seen it done before, care is taken so that the propagated errors from a given pixel always add up exactly.) | 19:46.11 |
| mvrhel | right | 19:46.22 |
| Robin_Watts_ | wheras here, rounding errors can occur. | 19:46.27 |
| mvrhel | oh yes. since you are coming from multiple sources and adding | 19:46.47 |
| | rather than propagating | 19:46.53 |
| Robin_Watts_ | BUT... I think he's working in 16bit accuracy here, so the errors are probably piddlingly small and always round down anyway. | 19:47.01 |
| mvrhel | ok | 19:47.07 |
| Robin_Watts_ | OK, so now he calculates an 'err' value. This is the 'biased error' value, I reckon. | 19:47.49 |
| mvrhel | so down to the non-white case | 19:47.50 |
| Robin_Watts_ | It starts off with new_e_1_0 (the error values passed in). | 19:48.08 |
| | He adds r_scratch | 19:48.16 |
| | then seasons with some random noise. | 19:48.28 |
| mvrhel | ok so new_e_1_0 is the standard error | 19:48.35 |
| Robin_Watts_ | Yes. | 19:48.46 |
| mvrhel | r_scratch[plane_idx] is the stuff from the distance calculation | 19:48.48 |
| | and then the random | 19:49.10 |
| Robin_Watts_ | right. | 19:49.19 |
| mvrhel | and then some more even clamping.... | 19:49.31 |
| Robin_Watts_ | So then he clamps the error. | 19:49.32 |
| | Actually... that comment is wrong. | 19:49.40 |
| | It's not for overflows. | 19:49.43 |
| mvrhel | under flow | 19:49.51 |
| Robin_Watts_ | It's for the 0.55 thing. | 19:49.58 |
| mvrhel | ok | 19:50.01 |
| | explain that one again | 19:50.16 |
| Robin_Watts_ | See section 6 of the paper :) | 19:50.43 |
| | It's voodoo. | 19:50.55 |
| mvrhel | right let me skim that quick | 19:50.56 |
| | ok that is not so clear all at | 19:51.43 |
| | so the error has some minimum value | 19:52.00 |
| | trying to think about what that does | 19:52.33 |
| | hold on phone | 19:52.38 |
| Robin_Watts_ | holding; I am tempted to put a "FIXME: Understand this" in there, and keep moving for now. | 19:54.12 |
| mvrhel | Robin_Watts_: that sounds good | 19:54.22 |
| Robin_Watts_ | you off the phone? | 19:54.32 |
| mvrhel | I am now | 19:54.44 |
| | that was my wife | 19:54.48 |
| Robin_Watts_ | ok, so then we have the coupling thing. | 19:54.53 |
| mvrhel | I have about 10 more minutes | 19:54.54 |
| Robin_Watts_ | ah, ok. | 19:55.01 |
| mvrhel | ok so yes coupling | 19:55.16 |
| Robin_Watts_ | The coupling gets mixed in with the unclamped error. We'll get on to how that's calculated in a mo. | 19:55.30 |
| | with the clamped error. (the coupling is not subject to clamping I mean). | 19:55.46 |
| mvrhel | looks like its getting added to the clamped error | 19:55.50 |
| | right | 19:55.54 |
| | I wonder if it should | 19:56.01 |
| | It would seem like it | 19:56.16 |
| Robin_Watts_ | The code is true to the paper, but I wondered the same. | 19:56.17 |
| mvrhel | ok. another note to make in the code | 19:56.40 |
| Robin_Watts_ | I thought I SHOULD be clamped when I thought the clamping was to do with avoiding over/underflows. | 19:56.45 |
| mvrhel | I hope you are writing these down :) | 19:56.50 |
| Robin_Watts_ | I am annotating the code as we go. | 19:56.59 |
| mvrhel | good deal | 19:57.03 |
| Robin_Watts_ | Then we calculate the quantised value. | 19:57.24 |
| mvrhel | so where was coupling computed? | 19:57.35 |
| Robin_Watts_ | we'll get there in a mo. | 19:57.50 |
| mvrhel | ok | 19:57.53 |
| Robin_Watts_ | For the first plane it's 0. | 19:57.55 |
| mvrhel | ok | 19:58.00 |
| Robin_Watts_ | imo should be in the range 0 to levels-1. | 19:58.22 |
| | IF it's not clamp it there. | 19:58.27 |
| mvrhel | line 1096 is not all that clear to me but I will assume it is thresholding | 19:59.09 |
| Robin_Watts_ | Then coupling_contribution (another nasty confusing variable name) is the classic FS error outbound from this pixel. | 19:59.14 |
| | mvrhel: Can you paste the line? My line numbers don't match up now :)_ | 19:59.46 |
| mvrhel | imo = ((err + im) * dith_mul + (1 << (EVEN_SHIFT + 7))) >> (EVEN_SHIFT + 8); | 19:59.53 |
| ray_laptop | Robin_Watts_: did you get rid of all of that 'seed*' and 'sum' (or is it actually used somewhere ?) | 19:59.54 |
| Robin_Watts_ | ray_laptop: That's part of the random noise stuff. | 20:00.20 |
| ray_laptop | doesn't have Robin_Watts's code. | 20:00.23 |
| Robin_Watts_ | The code has 2 different ways of calculating random noise, and that particular one was commented out in the code as it came to me. | 20:00.47 |
| | It's now in a switch so we can experiment. | 20:00.56 |
| mvrhel | Robin_Watts_: so lets keep moving forward | 20:01.08 |
| | looking at coupling_contribution | 20:01.12 |
| Robin_Watts_ | mvrhel: That is, I believe equation 7. | 20:01.20 |
| ray_laptop | Robin_Watts_: I see. so calculating the seed and sum if we are not going to use it should be in the switch, too ? | 20:01.41 |
| Robin_Watts_ | ray_laptop: It is. | 20:01.58 |
| | Or at least the per pixel work is. | 20:02.06 |
| mvrhel | Robin_Watts_: ok | 20:02.08 |
| | can you add in the comment that this is equation 7 | 20:02.21 |
| | that makes sense to me | 20:02.24 |
| Robin_Watts_ | done. | 20:02.37 |
| mvrhel | where are the plane weights used in coupling_contribution = im - ((imo * imo_mul) >> IMO_SHIFT); | 20:02.50 |
| Robin_Watts_ | not yet... | 20:03.00 |
| ray_laptop | mvrhel: that's the 'strengths' | 20:03.14 |
| mvrhel | ok weights strenghts | 20:03.25 |
| | Robin_Watts_: what is that line doing | 20:03.42 |
| Robin_Watts_ | Then coupling_contribution (another nasty confusing variable name) is the classic FS error outbound from this pixel. | 20:03.55 |
| mvrhel | oh | 20:04.07 |
| Robin_Watts_ | im = desired output pixel. | 20:04.10 |
| | (imo * imo_mul) >> IMO_SHIFT) = achieved output pixel. | 20:04.23 |
| mvrhel | yes. poorly named for this algorithm | 20:04.30 |
| | ok | 20:04.41 |
| Robin_Watts_ | Right, but the reason for that will become clear. | 20:04.45 |
| mvrhel | I see below that | 20:04.46 |
| Robin_Watts_ | So then we update the error passed in to get the error passed out. | 20:04.56 |
| mvrhel | right | 20:05.10 |
| Robin_Watts_ | new_e_1_0 += coupling_contribution; | 20:05.10 |
| | Then we get the actual coupling calculation. | 20:05.17 |
| mvrhel | right | 20:05.43 |
| | oh Robin_Watts_ I need to go for a bit | 20:06.11 |
| | like 30 minutes | 20:06.20 |
| Robin_Watts_ | mvrhel: OK | 20:06.25 |
| mvrhel | are you going to be around | 20:06.29 |
| Robin_Watts_ | I may be having dinner when you get back. I'll try and check back in afterwards, but otherwise we can pick this up again tomorrow? | 20:06.52 |
| mvrhel | Robin_Watts_: lets do that | 20:07.01 |
| Robin_Watts_ | cool. | 20:07.07 |
| mvrhel | I will also skim the rest my self | 20:07.12 |
| | if we don't meet up before tomorrow | 20:07.30 |
| Robin_Watts_ | If you could check my commit about correcting the weights, that would be good. | 20:07.35 |
| mvrhel | ok will do | 20:08.10 |
| | bbiaw | 20:08.12 |
| dave5 | Hi. I need to know if a given EPS file uses RGB colors or CMYK colors. | 21:01.04 |
| | i have a method that uses pswrite and pstoedit that works | 21:01.25 |
| | but is there a way i can use gs directly to give me the info? | 21:01.41 |
| | (I have been told to stop using pswrite, and move to ps2write... but i don't get the info i need using ps2write) | 21:02.18 |
| Robin_Watts_ | mvrhel: Changes pushed. | 21:13.56 |
| | Forward 1 day (to 2012/11/07)>>> | |
IRC Logs
