| | <<<Back 1 day (to 2012/11/06) | 2012/11/07 |
| kens | Oh my. I hoipe thats a typo in the latest email to support (we want to create PDF/A in under 15Kb memory) | 10:11.25 |
| sebras | tor8: ehm... you will reword the "WIP split muview..." title before you merge that commit to master, right? ;) | 11:54.29 |
| paulgardiner | quickly performs git fetch tor | 12:02.58 |
| paulgardiner | but doesn't find anything amusing. :-( | 12:05.05 |
| sebras | paulgardiner: git config --global alias.fetcha 'fetch --all --tags --prune' | 12:05.24 |
| | paulgardiner: that way I'll see changes that robin, you and tor make. | 12:05.45 |
| | since I have added each of your repos as remotes. | 12:05.57 |
| | this is also the reason I sometimes complain about the abundance of branches. ;) | 12:06.33 |
| | paulgardiner: I was thinking of commit f0f1c35 | 12:06.56 |
| paulgardiner | I was expecting to see that Tor had finally succumbed to expressing in a commit message his true love of gtk development. :-) | 12:09.32 |
| sebras | paulgardiner: :-D | 12:09.49 |
| tor8 | paulgardiner: almost. just almost. :) | 12:10.43 |
| | Robin_Watts_: sorry, was a bit tired yesterday. tagging you said? | 12:11.10 |
| Robin_Watts_ | tor8: yeah. If you tag a 'release', I'll pull it and do the builds etc. | 12:37.09 |
| tor8 | Robin_Watts_: just 'form-tech-preview' or '1.1-forms-tech-preview' or some other name? | 12:37.43 |
| Robin_Watts_ | the latter sounds better to me. | 12:38.08 |
| sebras | if you are building that for android, consider updating the .xml-file too. | 12:38.21 |
| tor8 | sebras: it's not an "official" release | 12:38.42 |
| sebras | tor8: right, nvm then. | 12:38.58 |
| tor8 | Robin_Watts_: tag pushed | 12:44.19 |
| Robin_Watts_ | tor8: Right. Will get right on that. | 12:45.18 |
| | kens: Good answer. | 13:21.24 |
| kens | good answer to what ? | 13:23.03 |
| Robin_Watts_ | 15kb. | 13:23.29 |
| kens | Oh yes, I'm sure that must be a typo (surel;y ?) | 13:23.47 |
| | I think Melanie's calculator has more memory than that | 13:24.10 |
| Robin_Watts_ | tor8, paulgardiner: Balls. | 13:51.26 |
| tor8 | problems? | 13:51.33 |
| Robin_Watts_ | I was hoping to make a release apk rather than a debug one. | 13:51.36 |
| | but we need to sign it. | 13:51.52 |
| tor8 | oh, but you need the signing crap for that don't you? | 13:51.59 |
| Robin_Watts_ | I wonder if I can make a debug apk with the release native code. | 13:52.08 |
| paulgardiner | I think I've done that before | 13:52.36 |
| Robin_Watts_ | paulgardiner: Do you want to put together a zip file of good example forms pdf files? | 13:58.04 |
| | or at least throw me some names? | 13:58.12 |
| paulgardiner | I've built up a directory of example which I've been using for testing as adding each feature. That would probably be a good start, I'd have thought. | 13:59.36 |
| Robin_Watts_ | Great. | 13:59.58 |
| paulgardiner | There you go: http://intranet.glidos.net/~paul/pdf-forms.zip | 14:05.28 |
| Robin_Watts_ | Thanks. | 14:06.43 |
| ManDay | Can anyone recommend a simple way to convert a PDF into a grayscale PDF? | 14:07.20 |
| kens | ManDay, not at present, come back in 6 montsh | 14:15.46 |
| ManDay | o_O | 14:19.26 |
| | Can you elaborate? | 14:19.32 |
| kens | I'm workning ons pdfwrite and evntually it will be able to do this, but not now | 14:24.32 |
| | hopefully in time for our next release in Fev | 14:24.54 |
| ManDay | kens: And ghostscript-gpl currently cannot do this? o_O | 14:25.01 |
| kens | February | 14:25.02 |
| | Not easily | 14:25.09 |
| | I'll answer the russian in a bit | 14:42.17 |
| mace | ManDay: random thought, if it's a one page pdf, then gimp might be sufficient | 14:42.54 |
| | won't be pretty though | 14:42.58 |
| ManDay | ... | 14:44.12 |
| | Not only not pretty | 14:44.20 |
| | It's gonna be a picture, afterwards, wth | 14:44.27 |
| mace | indeed | 14:56.05 |
| ManDay | A beautiful, 200 Mb picture... | 15:00.17 |
| Robin_Watts_ | paulgardiner: So, our file selector doesn't do directories. Damn. | 15:08.46 |
| paulgardiner | No, but you can invoke mupdf from any file manager | 15:09.34 |
| kens | ManDay try -sDEVICE=pdfwrite -sProcessColorModel=DeviceGray -dUseCIEColor -sColorCOnversionStrategy=/Gray | 15:10.51 |
| Robin_Watts_ | paulgardiner: OK, my android thing doesn't seem to be doing forms | 15:11.00 |
| kens | -sColorConversionStrategy | 15:11.07 |
| Robin_Watts_ | Do I need to change anything to make the build work? | 15:11.11 |
| paulgardiner | Besides using "V8_BUILD=yes ndk-build" for the native part, not as far as I know | 15:12.44 |
| Robin_Watts_ | And that's what I cocked up. Thanks. | 15:13.06 |
| | Hmm. | 15:23.24 |
| j00ru | hey guys, can I find any mupdf devs here? ;) | 15:25.31 |
| kens | I can see at least 3 from here :-) | 15:30.32 |
| j00ru | and they are... ? :> | 15:31.53 |
| kens | Robin_Watts_ : tor8 paulgardiner | 15:32.07 |
| sebras | kens: hey!! | 15:32.44 |
| kens | sorry sebras didn't see you | 15:32.52 |
| paulgardiner | hi kens | 15:32.59 |
| j00ru | thanks kens | 15:33.13 |
| sebras | kens: not that I'm particularly more trustworthy today compared to yesterday though... | 15:33.13 |
| | j00ru: did you have a mupdf-related question? something tells me that you were not only looking for a list of nicks...? | 15:36.42 |
| j00ru | yes, I have some security issues to report in mupdf and wanted to contact the devs directly before filing bugs in tracker / taking any other action. | 15:38.37 |
| sebras | j00ru: ok, thanks for taking the time to report any issues you find. :) | 15:39.45 |
| j00ru | ;-) | 15:40.16 |
| henrys | once again Florida can't seem to count the damn votes - unbelievable ... | 15:51.08 |
| kens | really ? Not heard that on the news | 15:51.24 |
| Robin_Watts_ | FFS. How hard can it be to make electronic voting machines that actually work? | 15:51.49 |
| henrys | well mvrhel and I can smoke pot now (actually the feds say no the states says yes). The meetings might take longer. | 15:54.48 |
| | ;-) | 15:54.55 |
| Robin_Watts_ | gah. My ant installation is broken. | 15:57.05 |
| henrys | is that needed for the apk? | 15:57.53 |
| Robin_Watts_ | yeah. | 15:58.46 |
| | My fault. I moved java off the SSD and that's upset it. | 15:58.57 |
| sebras | Robin_Watts_: I guess you have already seen youtube clips of machines not obeying voter selections? | 16:02.30 |
| Robin_Watts_ | sebras: I am aware of their existence. | 16:03.09 |
| | We have hi-tech disposable voting machines here which offer a simple UI on a carbon based substrate whereby people trace a glyph near the appropriate menu choice using a graphite based stylus. | 16:06.18 |
| | Also known as pencil and paper. | 16:06.35 |
| sebras | Robin_Watts_: but that seems so ineffiencent! and I can't for the life in me believe that using that kind of tech won't fail miserably eventually... | 16:07.52 |
| henrys | the basic problem in the US is each state has its own system. I think if we just agreed on one voting system machine, pencil whatever it would work better. | 16:09.21 |
| Robin_Watts_ | sebras: The thing I like most about it is the way that at the count, people bundle the votes together into votes of the same type. | 16:09.40 |
| | Then they 'flipbook' through them to check that there aren't any of the wrong type in each bundle. | 16:10.08 |
| | henrys: Voting machines are fundamentally incapable of fulfilling the basic requirements of the system, namely 1) anonymity and 2) trust. | 16:12.34 |
| | I mean, I'm a tech head - given two choices in how to do something I'll generally go for the one that involves the most clever gadgetry, but really for voting, pencil/paper/ballot box wins every time. | 16:13.23 |
| henrys | for those of us that consider a short wait in line to be fundamental to the basic requirement I have to disagree. | 16:15.55 |
| | I know canada is using the internet which seems pretty crazy and some states will except _EMAIL_ clear text ... unbelievable | 16:17.26 |
| paulgardiner | We use apathy to keep our voting queues short. | 16:18.18 |
| sebras | paulgardiner: :) | 16:18.35 |
| Robin_Watts_ | henrys: In my experience of voting I have never had to wait for a voting booth. | 16:18.46 |
| | The time to actually vote with a pencil and paper is WAY less than the time to use an electronic machine. | 16:19.18 |
| henrys | 4 and 5 hours waits occurred yesterday. It isn't just convenience, it effectively disenfranchises many people who simply can't do that, job family whatever. | 16:20.36 |
| Robin_Watts_ | henrys: Right, and what's the holdup there? | 16:20.49 |
| | Is it the queuing for the limited number of voting machines? | 16:21.10 |
| | Or the queuing to find peoples names on the register of voters? | 16:21.27 |
| | The choice of voting machine vs paper will have no impact on the length of the queues if it's the latter. | 16:22.01 |
| | And if it's the former, well, remove the expensive voting machines from the equation and it becomes much much easier to shrink the queues. | 16:22.25 |
| henrys | it looks like a lot of it was voter id laws so you might be right. | 16:24.38 |
| Robin_Watts_ | No id required in the UK. | 16:27.58 |
| | We get a voting card sent through the post to every registered voter, but you don't need to take it along. | 16:28.20 |
| henrys | I'm reading that you guys are starting to use internet voting. | 16:28.33 |
| Robin_Watts_ | You give your name, they cross you off the list, you vote. Takes about 30 seconds. | 16:28.38 |
| | The last government wanted to push for postal voting, and they ran a trial in birmingham. | 16:28.56 |
| | The result was voting fraud on a massive scale. | 16:29.11 |
| henrys | I do vote by mail. | 16:30.00 |
| Robin_Watts_ | You can vote by mail if you want to here. | 16:30.51 |
| | but I've never seen the point. | 16:30.58 |
| henrys | my mailman picks it up at my house. I always wonder if he looks for a sign in the yard and loses the ballot selectively. | 16:31.22 |
| Robin_Watts_ | (The polling station is 2 minutes walk, and the process takes less than 2 mins) | 16:31.23 |
| | henrys: Our mail men only drop off. | 16:32.00 |
| | tor8: I figure on: mupdf-v8-windows.zip (which will contain mupdf-v8.exe) and mupdf-tools-windows.zip (which will contain mudraw.exe and mutool.exe) | 16:37.25 |
| | I don't see the point in shipping mujstest-v8.exe or mupdf.exe do you ? | 16:37.46 |
| | paulgardiner: oh eck. | 16:47.37 |
| paulgardiner | Eek! What? | 16:48.12 |
| Robin_Watts_ | I've got a problem with the android version of mupdf here - are you in a position to check something at your end? | 16:48.16 |
| | Start mupdf. Load calc.pdf. | 16:48.22 |
| paulgardiner | Sure | 16:48.23 |
| Robin_Watts_ | Enter some values on page 1. all works fine. | 16:48.32 |
| | Then pan to page 2... | 16:48.37 |
| paulgardiner | Showing the first page on the second? | 16:48.45 |
| Robin_Watts_ | yes. | 16:48.48 |
| paulgardiner | Yes. I have seen that. | 16:49.19 |
| Robin_Watts_ | Ah. I reckon that's a fair old show stopper personally. | 16:49.39 |
| paulgardiner | I keep forgetting to trakc it down | 16:49.46 |
| | It was a rare occurence, but happens more now we have forms support. | 16:51.08 |
| Robin_Watts_ | oh, I assumed this was because of the 'cache 3 pages' stuff. | 16:51.45 |
| paulgardiner | No. It's been there a long time, although it was very rare. It's useful that it is more easily triggered now, because that should help tracking it down. | 16:52.42 |
| | I intended to look at that today, but forgot again. | 16:53.17 |
| | Hoepfully a concerted effort will trace it. | 16:53.58 |
| Robin_Watts_ | OK, so I'll put what I've got up for testing etc, and hopefully we can fix that, and we can retag/rebuild. | 16:55.18 |
| paulgardiner | The fact that all the public MUPDFCore methods are synchronized makes it hard to understand. | 16:55.30 |
| aleray | hi, is it possible to redirect the output of a ghostscript command rather than to a file? | 16:55.33 |
| tor8 | Robin_Watts_: what's the point of mupdf-tools-windows.zip then? it's got nothing to do with the forms :) | 16:56.03 |
| Robin_Watts_ | tor8: It's an updated version of the tools to replace the existing ones that don't work on XP. | 16:56.49 |
| ray_laptop | aleray: yes. the -sOutputFile=___ captures the printer/image output of the rendered page (or pdf) in the specified file | 16:56.54 |
| Robin_Watts_ | tor8: And it's possible that the forms announcement may drag people in to discover mupdf for the first time. | 16:57.22 |
| aleray | ray_laptop, -sOutputFile=- you mean? | 16:57.24 |
| ray_laptop | aleray: and -sstdout=___ -sstderr=___ allow redirection of stdout and stderr in case your OS doesn't support it | 16:57.27 |
| aleray | I will try | 16:57.28 |
| | ray_laptop, three underscores? | 16:57.42 |
| ray_laptop | aleray: no, ___ is where you specify your path for the files | 16:58.00 |
| tor8 | Robin_Watts_: oh, right. so why not a mupdf-1.1-v8-windows.zip with both the updated tools and mupdf-v8 and mupdf non-v8 ? | 16:58.25 |
| henrys | aleray:gs/doc/Use.htm | 16:58.37 |
| ray_laptop | NO underscores. e.g. -sstdout=mystdout.txt -sOutputFile=myfile.jpg ... | 16:58.38 |
| aleray | ray_laptop, I'm writing a python program, and I would like to avoid to write the output file on disk | 16:58.44 |
| Robin_Watts_ | tor8: Normally you put tools in a separate zip file. | 16:58.48 |
| tor8 | Robin_Watts_: I didn't for the last release though | 16:59.12 |
| Robin_Watts_ | But I'm happy to put 'em all in together. | 16:59.16 |
| | So both mupdf's and tools. | 16:59.26 |
| | Do you agree about no mujstest ? | 16:59.34 |
| ray_laptop | aleray: iirc, when you run an external program from python, the python captures the stdout and stderr, but I haven't played with it for a while. | 16:59.52 |
| tor8 | yes. it seems a bit useless outside of artifex :) | 16:59.53 |
| Robin_Watts_ | tor8: It's useless unless you're actually building from source, I reckon, at least. | 17:00.09 |
| ray_laptop | aleray: what works depends on which version python, IIRC | 17:00.20 |
| aleray | ray_laptop, i'm looking into it | 17:00.30 |
| ray_laptop | aleray: from the python docs on the 'sys' module: | 17:02.36 |
| | stdin -- standard input file object; used by input() | 17:02.38 |
| | stdout -- standard output file object; used by print() | 17:02.39 |
| | stderr -- standard error object; used for error messages | 17:02.41 |
| | By assigning other file objects (or objects that behave like files) | 17:02.42 |
| | to these, it is possible to redirect all of the interpreter's I/O. | 17:02.44 |
| marcosw | I found a web page with some good ideas for improving our regression scripts: http://thedailywtf.com/Articles/Psychic-Code.aspx | 17:05.45 |
| ray_laptop | aleray: Also check the docs on python 'pipes' module: The module lets you construct a pipeline template by sticking one or more conversion steps together. It will take care of creating and | 17:06.11 |
| | removing temporary files if they are necessary to hold intermediate data. | 17:06.12 |
| aleray | ray_laptop, thanks. I'm ok on this point actually | 17:06.32 |
| | another question is can I feed gs with stdin instead of a file name ? | 17:06.54 |
| ray_laptop | marcosw: do you have a dog ? | 17:07.20 |
| | aleray: yes, as henrys said "doc/Use.htm" the '-' option tells ghostscript to read from stdin | 17:08.02 |
| marcosw | no, we have two guinea pigs | 17:08.03 |
| ray_laptop | marcosw: I guess they could manage to chew up regex's an emit pellets that you could put into the cluster code :-) | 17:08.45 |
| mvrhel | good morning | 17:08.49 |
| aleray | cool | 17:08.50 |
| ray_laptop | aleray: the other thing you may want is -q (to limit the noise on stdout) | 17:09.18 |
| | morning, mvrhel | 17:09.26 |
| marcosw | the guinea are excellent at eating paper, so will probably make a reasonable dog substitute | 17:09.36 |
| aleray | ray_laptop, what do yo umean by noise? | 17:09.45 |
| kens | alreay all the other stuff that gets emitted there that you don't want to se because you aren't interested in it | 17:10.43 |
| ray_laptop | aleray: things lilke: GPL Ghostscript GIT PRERELEASE 9.07 (2012-07-31) | 17:11.18 |
| | Copyright (C) 2012 Artifex Software, Inc. All rights reserved. | 17:11.20 |
| | This software comes with NO WARRANTY: see the file PUBLIC for details. | 17:11.22 |
| aleray | ray_laptop, ah ok | 17:11.35 |
| | ray_laptop, ah it was already enabled in my cmd line | 17:11.55 |
| ray_laptop | aleray: and if you want ghostscript to actually execute stdin, make sure each PostScript input command terminates with whitespace (new-line is common) | 17:13.31 |
| Robin_Watts_ | ah, morning mvrhel. | 17:14.12 |
| mvrhel | good morning Robin_Watts_ just looking over your commits | 17:14.33 |
| ray_laptop | aleray: a common mistake is to send "(myfile.ps) run" to stdin and discover it doesn't do anything. You need "(myfile.ps) run\n" | 17:14.36 |
| lost711 | evening all, I'm curious if some of the older bugs that are marked 'bountiable' are still valid for collecting bounties? | 17:15.05 |
| Robin_Watts_ | lost711: if they say bountiable, they are still eligible, I believe. Which ones in particular ? | 17:15.35 |
| kens | As far as I'm aware if htey are open and marked as bountiable, then you are fine | 17:15.42 |
| lost711 | The windows spooler one | 17:15.56 |
| kens | can you give us a number ? | 17:16.10 |
| lost711 | Digging it | 17:16.14 |
| | chrome tab crashed :-/ | 17:16.22 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=690595 | 17:16.58 |
| kens | As far as I can tell there's no reason why that shouldn't be bountiable. | 17:18.03 |
| mvrhel | Robin_Watts_: I had thought you said you had a commit that fixed an issue with the weight or strengths of the distance propagation amongst planes but I could not find that in the commits. Anyway we can keep pushing on | 17:18.08 |
| lost711 | I'm downloading the GS source now to get a feel for it, and work on that and some of the other bounty bugs :-) | 17:18.35 |
| kens | lost711 : you may want topost any ideas or findings to the bug report though, so that you don't waste time with somethign we won't accept | 17:18.38 |
| mvrhel | Robin_Watts_: actually let me see if I can get rock and scroll in place in visual studio 2012 first | 17:18.40 |
| lost711 | is there a copyright assignment or somethng similar required for upstream contribution? | 17:18.52 |
| kens | lost711 : yes, there is, but I'm not an expert in this | 17:19.07 |
| Robin_Watts_ | lost711: Yes. | 17:19.08 |
| mvrhel | or RockScroll I guess it is called | 17:19.24 |
| Robin_Watts_ | Metal Scroll I believe | 17:19.32 |
| | RockScroll was the original, MetalScroll is a new one that's better... for some reason I can't remember. | 17:19.59 |
| lost711 | Fair enough. I need to finish wrapping my brain around ghostscript before doing any patch writing though | 17:20.01 |
| Robin_Watts_ | mvrhel: While I was testing I had the strengths for CMYK stuff broken for a while, but I went back and fixed it. | 17:20.14 |
| | The error was in the test code, and I rewrote the history so it was saner. | 17:20.23 |
| mvrhel | ok | 17:20.32 |
| | let me get metalscroll then... | 17:20.39 |
| | actually metalmargin | 17:22.27 |
| Robin_Watts_ | http://code.google.com/p/metalscroll/ | 17:23.11 |
| mvrhel | aha | 17:24.01 |
| | ok | 17:24.03 |
| Robin_Watts_ | no, you're right. | 17:24.08 |
| | metal margin is metalscroll redone for VS2010 | 17:24.23 |
| mvrhel | oh ok | 17:24.32 |
| | ok I will have to fool with this later. Robin_Watts_ lets push forward so it does not get too late for you | 17:26.16 |
| Robin_Watts_ | ok, so I think we'd basically got all the way through yesterday, but had left various things to come back to. Is that right? | 17:27.01 |
| ray_laptop | mvrhel: it is also supposed to be in MS's add-in pack called Productivity Power Tools | 17:27.20 |
| mvrhel | ray_laptop: ok I will look into it later | 17:27.38 |
| | thanks | 17:27.40 |
| | Robin_Watts_: I thinkn we were at line 1129 | 17:28.00 |
| Robin_Watts_ | coupling += ... | 17:28.19 |
| mvrhel | yes | 17:28.23 |
| kens | Goodnight folks. | 17:29.01 |
| Robin_Watts_ | That's equation 6. | 17:29.10 |
| ray_laptop | has the git code now to follow along | 17:29.25 |
| Robin_Watts_ | coupling_contribution = "acheived error" = gj - tj | 17:29.30 |
| ray_laptop | night, kens | 17:29.31 |
| mvrhel | so the ccoupling_contribution is the error computed in line 1120 | 17:29.36 |
| | and the variable coupling is updated with this | 17:29.53 |
| Robin_Watts_ | Right | 17:30.01 |
| | coupling is k in equation 6. | 17:30.12 |
| mvrhel | and coupling will be used for the next plane | 17:30.16 |
| Robin_Watts_ | right. | 17:30.20 |
| mvrhel | So the error is sort of propagated to the next plane as we go through? | 17:30.45 |
| | that seems a bit different than I had expected | 17:30.51 |
| Robin_Watts_ | Yes, me too now you come to mention it. | 17:31.05 |
| mvrhel | So the next plane could squash the error | 17:31.38 |
| Robin_Watts_ | Let's just think about this; we're dealing with the black plane first. | 17:31.39 |
| mvrhel | ending any propagation | 17:31.42 |
| | which seems reasonable actually | 17:31.53 |
| Robin_Watts_ | No. it's not added to the error. It's added to the bias. | 17:31.57 |
| ray_laptop | doesn't increasing the error make it MORE likely to produce a dot (or are the signs inverted) ? | 17:32.01 |
| mvrhel | Robin_Watts_: yes ok | 17:32.16 |
| Robin_Watts_ | Suppose we put a black dot out when we were really only expecting a midtone. | 17:32.30 |
| | That means the error is going to be negative as we've put out more ink that we'd expect. | 17:32.47 |
| mvrhel | right | 17:33.00 |
| Robin_Watts_ | So coupling_contribution < 0 | 17:33.02 |
| mvrhel | right | 17:33.10 |
| Robin_Watts_ | so the next plane will be biased away from producing a dot. | 17:33.20 |
| mvrhel | ok. that seems reasonable | 17:33.30 |
| Robin_Watts_ | but the error propagated from that component will still be correct, so we'll get the right amount of ink overall in the end. | 17:33.50 |
| | Ok. it makes a kind of sense at least. | 17:33.59 |
| mvrhel | one question | 17:34.34 |
| Robin_Watts_ | go on (just running to fridge) | 17:34.44 |
| mvrhel | line 1103 shows the coupling being added to err | 17:35.00 |
| ray_laptop | and if we produce a dot on the next plane following the first, how does that prevent us from putting a dot on the third plane under the black ? | 17:35.07 |
| mvrhel | prior to line 1109 where we do the quantization | 17:35.28 |
| Robin_Watts_ | mvrhel: Right. | 17:35.43 |
| | ray_laptop: coupling is cumulative. | 17:36.01 |
| mvrhel | I suppose adding to the error is the same as biasing the threshold | 17:36.13 |
| | as long as the subsuquent error calcuation is correct | 17:36.33 |
| Robin_Watts_ | so plane 0 has coupling=0. plane 1 has coupling from plane 0. plane 2 has coupling from plane 0 + plane 1. | 17:36.36 |
| | mvrhel: It's a bad variable name | 17:36.43 |
| mvrhel | yes | 17:36.50 |
| Robin_Watts_ | err is really 'error+bias' | 17:36.53 |
| mvrhel | It would be nice to rename that | 17:36.55 |
| | ok | 17:36.57 |
| ray_laptop | Robin_Watts_: OK, right I see. | 17:37.00 |
| Robin_Watts_ | I had it renamed to bias for a while, but the problem is that the error is added in there as well before clipping, so even bias isn't quite right. | 17:37.30 |
| mvrhel | right | 17:37.42 |
| Robin_Watts_ | I'm open to suggestions for better names :) | 17:38.03 |
| ball | I think you should call it "Dave" | 17:38.15 |
| Robin_Watts_ | ball: I'd get it confused with the TV channel. | 17:38.35 |
| mvrhel | A comment there would be nice just so that it is clear that we are using the coupling as a bias in the subsequent quantization calculation | 17:38.47 |
| ball | Is there a TV channel called "Dave"?! | 17:39.00 |
| Robin_Watts_ | ball: There is. | 17:39.08 |
| ball | Well that's a bit odd. | 17:39.18 |
| Robin_Watts_ | mvrhel: A comment where? | 17:39.19 |
| mvrhel | above err += coupling; | 17:39.34 |
| | where you have the question about clamping | 17:39.49 |
| ray_laptop | A guy that worked for me once used to use all girls names for branch targets in .asm (he got tired of thinking up 8 character meaningful names) | 17:39.59 |
| mvrhel | ha | 17:40.08 |
| | ok so line 1132 | 17:40.50 |
| | so if we put a dot out, things get reset | 17:41.11 |
| Robin_Watts_ | /* Add the coupling to our combined 'error + bias' value */ ? | 17:41.14 |
| mvrhel | that is fine | 17:41.21 |
| Robin_Watts_ | If we put a dot out, we reset the distance measurements, yes. | 17:41.44 |
| ball | I think this photocopier hates me. | 17:42.05 |
| mvrhel | then we have some fancy stuff | 17:42.21 |
| ray_laptop | Robin_Watts_: right, as described in eq. 3 | 17:42.34 |
| mvrhel | and we end the main loop | 17:43.02 |
| | so what is going on in line 1167.... | 17:43.41 |
| Robin_Watts_ | mvrhel: We end the forward pass loop, yes. | 17:43.44 |
| ray_laptop | mvrhel: that just ends that plane's calc. then we save the planes values and end the main loop | 17:44.20 |
| Robin_Watts_ | The way the algorithm works for maintaining the distance metrics is that after we have done a forward pass to generate a line of pixels, we then need to run backwards across the line. | 17:44.26 |
| | mvrhel: That's the application of equation 4 from the paper. | 17:45.09 |
| | ray_laptop: We're a bit further on than that. | 17:45.17 |
| mvrhel | ok. so we have already decided if we are or are not outputting a dot. and now we are updating the reverse direction errors for the next time we come in here | 17:45.29 |
| Robin_Watts_ | yes. | 17:45.47 |
| mvrhel | which is that pile of equations with the multiple prime symobls | 17:45.49 |
| | ok | 17:45.51 |
| Robin_Watts_ | yeah. | 17:45.55 |
| mvrhel | ok. I think that finishes us then | 17:46.10 |
| Robin_Watts_ | Now, I had some more thoughts about the white count stuff last night, and thought I'd got it figured out in my head. | 17:46.12 |
| | but then on my run this morning I convinced myself that even if I make the fixes I had in mind, it'd still be broken. | 17:46.48 |
| | but anyway... | 17:47.01 |
| | So, we put pins in various bits to come back to. | 17:47.13 |
| mvrhel | Robin_Watts_: so where are we now and what do you think needs to be done / addressed | 17:47.18 |
| Robin_Watts_ | do you remember where? :) | 17:47.33 |
| mvrhel | I thought you were taking notes in the code :0 | 17:47.47 |
| Robin_Watts_ | Yeah, there are FIXMEs. | 17:47.55 |
| mvrhel | good eal | 17:48.00 |
| | deal | 17:48.02 |
| Robin_Watts_ | I see 3 FIXMEs. | 17:48.24 |
| ray_laptop | what about multiple levels (and the transition and dot size compensation questions) ? | 17:48.34 |
| Robin_Watts_ | 1) Understand the clamping to 0.55 * ... | 17:48.36 |
| mvrhel | that fixme is in line 1792 | 17:48.44 |
| Robin_Watts_ | 2) Understand why the coupling isn't clamped | 17:48.52 |
| mvrhel | and then 3) is ray's comment | 17:49.05 |
| Robin_Watts_ | 3) indeed. | 17:49.10 |
| mvrhel | which we don't believe is addressed | 17:49.24 |
| Robin_Watts_ | There should be one for 4) fix the damn white skipping code. | 17:49.36 |
| mvrhel | yes I agree | 17:49.45 |
| | Robin_Watts_: so are you seeing artifacts from it not working? | 17:49.58 |
| Robin_Watts_ | mvrhel: No, because tiger.pam has a grey background :) | 17:50.15 |
| mvrhel | Do you see any diffs with it on or off on something with chunks of white | 17:50.30 |
| ray_laptop | but even with the relative dot size taken into account, Max was commenting that the transitions where not 'smooth'. Do we expect that having rand_luts for the transitions will solve that ? | 17:50.34 |
| Robin_Watts_ | mvrhel: Let's come back to that in a mo. | 17:50.49 |
| ray_laptop | Robin_Watts_: try colorcir.ps (colorcir.pam) | 17:51.12 |
| Robin_Watts_ | ray_laptop: I think we should all look at some output together so we can agree what the state of play is. | 17:51.13 |
| mvrhel | rand_luts are a mistake or a crutch for something that is broken also I believe but that is another story | 17:51.18 |
| Robin_Watts_ | mvrhel: Right exactly. | 17:51.26 |
| | So, if we all open the following link in a browser... | 17:51.49 |
| | http://ghostscript.com/~robin/ETS/ | 17:52.04 |
| ray_laptop | Robin_Watts_: OK. | 17:52.29 |
| Robin_Watts_ | Pop the browser to full screen, and open the following images in a tab each... | 17:52.43 |
| | tiger_m*_e*_r*.png | 17:53.01 |
| | In chrome, the pictures appear zoomed in, so click on them once to make them real sized. | 17:53.29 |
| mvrhel | ok | 17:53.30 |
| Robin_Watts_ | If you scroll up into the top left corner in all of them, and then navigate around by moving in page sizes using the scrollbar, you can swap between tabs and see differences very easily. | 17:54.42 |
| | (Does that make sense?) | 17:54.48 |
| mvrhel | yes. let me do that | 17:55.03 |
| ray_laptop | Robin_Watts_: right. works for me. | 17:56.06 |
| Robin_Watts_ | Oh, and open tiger_fsonly.png too | 17:56.13 |
| | tiger_fsonly.png is tiger_m0_e0_r0.png really. | 17:56.40 |
| | I have added -m -e and -r flags to the tests. | 17:56.53 |
| | -m 0 or 1 enables or disables multiplane optimisations. | 17:57.05 |
| | -e 0 or 1 disables or enables ETS biasing | 17:57.24 |
| | -r determines the style of random noise used. | 17:57.38 |
| ray_laptop | Robin_Watts_: I was noticing that m0_e0_r0 looked a lot like fsonly | 17:58.02 |
| Robin_Watts_ | ray_laptop: There is no m0_e0_e0 | 17:58.38 |
| ray_laptop | m1_e1_r2 looks pretty grainy | 17:58.39 |
| | meant m1_e0_r0 | 17:58.49 |
| Robin_Watts_ | So comparing tiger_fsonly.png and tiger_m1_e0_r0.png shows the effect of turning on multiplane optimisations. | 17:58.50 |
| | You can really see the difference if you look at the 'crows feet' above the tigers nose. | 17:59.14 |
| mvrhel | ok so I have my favorite | 17:59.28 |
| ray_laptop | I see narrow 'red' stripes in the orange | 17:59.39 |
| mvrhel | I do not like any of the random ones | 17:59.40 |
| ray_laptop | my fav. is m1_e1_r1 just because the orange looks smoother | 18:00.00 |
| mvrhel | both m1_e0 and m1_e1 are better than FS | 18:00.03 |
| Robin_Watts_ | Right. turning multiplane opts on is a big win I reckon. | 18:00.21 |
| mvrhel | e1 looks better in the tooth | 18:00.22 |
| | than e0 | 18:00.35 |
| Robin_Watts_ | I find it hard to have a strong opinion between e1 and e0 personally. | 18:01.15 |
| mvrhel | so m1-e1 | 18:01.18 |
| | look at the patterns in the tooth | 18:01.27 |
| | with m1_e0 | 18:01.30 |
| | the left canine | 18:01.35 |
| Robin_Watts_ | His left or our left? | 18:01.53 |
| | :) | 18:01.55 |
| mvrhel | ok his right | 18:02.01 |
| | the magenta dots | 18:02.05 |
| | have a bit of a pattern that e1 seems to break up | 18:02.14 |
| | that is being picky | 18:02.23 |
| | but | 18:02.25 |
| Robin_Watts_ | OK. Look at the right hand side (our right) of his mouth. | 18:02.40 |
| | In the darkest purple bit. | 18:02.53 |
| mvrhel | oh | 18:02.58 |
| | ick | 18:02.59 |
| | yes | 18:03.01 |
| | we should find out what that is | 18:03.12 |
| Robin_Watts_ | I wonder if that's overflow. | 18:03.14 |
| | Indeed. | 18:03.16 |
| mvrhel | that is a nice example of a problem | 18:03.29 |
| Robin_Watts_ | OK, so ready to consider the different random ones? | 18:03.46 |
| mvrhel | I dont like any of them | 18:04.20 |
| Robin_Watts_ | Me either. | 18:04.25 |
| | If you look at the plain grey background it looks 'grainier' with random noise. | 18:04.40 |
| | but more worrying is what it does to graduations. | 18:04.49 |
| | Look at the section just above his nose. | 18:05.00 |
| mvrhel | I would expect it t wash them out | 18:05.03 |
| Robin_Watts_ | and in the graduations around his eyes. | 18:05.44 |
| mvrhel | I don't like the black areas on his nose for sure | 18:06.15 |
| Robin_Watts_ | actually... I should probably regenerate these images to make sure they are entirely up to date. | 18:06.48 |
| | Can you bear with me for a bit while I do that? | 18:06.55 |
| mvrhel | sure | 18:06.59 |
| | I will work on getting the VS tools for a bit | 18:07.16 |
| | looking into ray's suggestion of Productivity Power Tools | 18:07.54 |
| | has a nice name... | 18:08.03 |
| ray_laptop | mvrhel: for the gradations above the nose, r>0 smooths them out. Is that what you meant by 'wash out' ? | 18:08.34 |
| mvrhel | yes. no major contours | 18:08.50 |
| | which can be ok | 18:09.02 |
| | but the black area on his nose is bad | 18:09.14 |
| ray_laptop | mvrhel: the solid black ? (or the gray at the base of the whiskers)? | 18:09.46 |
| mvrhel | ray_laptop: it may be that we need better luts | 18:09.48 |
| | oh that is interesting | 18:10.17 |
| | yes. ray I guess that is supposed to be gray | 18:10.26 |
| | now the other non random ones have that very black | 18:10.39 |
| | or more so | 18:10.54 |
| Robin_Watts_ | mvrhel: I'm worried that some of these may not be quite right, hence me regenerating. | 18:11.01 |
| mvrhel | ok. we will wait | 18:11.09 |
| ray_laptop | Robin_Watts_: OK. | 18:11.14 |
| mvrhel | Thanks Robin_Watts_ | 18:11.16 |
| Robin_Watts_ | ok uploading now... | 18:14.57 |
| ray_laptop | was there info somewhere on how the tm was derived ? | 18:18.38 |
| Robin_Watts_ | tm = random noise. | 18:18.58 |
| mvrhel | oh are the files up now? | 18:19.12 |
| Robin_Watts_ | all except the random ones. | 18:19.23 |
| | still uploading. | 18:19.27 |
| ray_laptop | if we used a blue noise random we might get better | 18:19.37 |
| Robin_Watts_ | OK. so m0_e0_r0 -> m1_e0_r0 is a no brainer to me. | 18:20.50 |
| | All uploaded. | 18:20.59 |
| mvrhel | ok opening.... | 18:21.19 |
| Robin_Watts_ | anyone going to disagree with that? | 18:23.27 |
| ray_laptop | m0_e0_r0 has purple stripes in the red (others are black.) Colors shouldn't change that much ! | 18:24.15 |
| mvrhel | where? | 18:25.10 |
| Robin_Watts_ | ray_laptop: Some of this may be to do with the fact that these are rgb pngs from cmyk pams. | 18:25.23 |
| mvrhel | I am not going to be too concerned about color shifts. really the way one does is is picks a HT method to reduce artifacts and then color manages | 18:25.39 |
| ray_laptop | Robin_Watts_: but black dots totally obliterate the color, right ? | 18:25.53 |
| Robin_Watts_ | ray_laptop: Right. Where are you looking ? | 18:26.09 |
| ray_laptop | Robin_Watts_: the 'black' lines on the red stripes on the muzzle above the nose toward the tiger's left eye | 18:27.29 |
| Robin_Watts_ | ray_laptop: If you look at tiger_source.png you'll note that those aren't supposed to be black lines. | 18:28.21 |
| ray_laptop | e1_r0 is mostly black. e1_r1 is purple lines, as is m0_e0_r0 | 18:28.22 |
| mvrhel | ray_laptop: you mean where I was talking earlier? | 18:28.35 |
| Robin_Watts_ | They are supposed to be brown. | 18:28.45 |
| ray_laptop | compare to CMYK from gswin32c -r360 -dDisplayFormat=16#20808 examples/tiger.eps | 18:28.49 |
| Robin_Watts_ | ray_laptop: Much more sensible to compare with tiger_source.png as that's generated from the source pam that is used to generate all the others from. | 18:29.26 |
| mvrhel | ok. again. color shifts are not super critical here and can be expected especially since we are doing a soft copy preview | 18:29.33 |
| | I would focus more on an structural issues | 18:29.50 |
| | s/an/any/ | 18:29.59 |
| Robin_Watts_ | So is anyone going to disagree about m1 being much better than m0 ? | 18:30.45 |
| mvrhel | structure wise I like m1 better | 18:30.56 |
| | quit a bit actually | 18:31.28 |
| ray_laptop | those are fairly extensive color shifts, in an area with some C+M+Y+K I think we need to keep this on the list (may be related to / caused by the coupling) | 18:31.29 |
| | I agree that m1_e0_r0 is much better than m0 | 18:31.53 |
| Robin_Watts_ | Ok, so let's look at m1_e0_r0 vs m1_e1_r0 ? (i.e. does ETS help or harm) | 18:31.57 |
| mvrhel | again in the canine, the structures are less in e1 | 18:32.44 |
| | but we do have more spots in that deep magenta region | 18:32.59 |
| | below his tounge | 18:33.14 |
| | that are bright | 18:33.24 |
| Robin_Watts_ | I am inclined to think that ETS doesn't make a blind bit of difference, EXCEPT in the case where we are in a very pale region. | 18:33.37 |
| mvrhel | It would be good to find out what those are | 18:33.38 |
| | yes | 18:33.44 |
| | in the highlights | 18:33.49 |
| | where the dots are noticable | 18:33.57 |
| ray_laptop | I agree m1_e1_r0 is slightly better (and still no color shift). But I see the white dots in the purple below the tongue | 18:34.04 |
| Robin_Watts_ | Which makes me wonder if we shouldn't weight the ets adjustment. | 18:34.23 |
| mvrhel | weight it based upon the level? that is it kicks in more in the hightlights | 18:35.02 |
| | and none in the shadows | 18:35.18 |
| Robin_Watts_ | mvrhel: Have the weighting drop to zero in the midtones I was thinking. | 18:35.28 |
| mvrhel | yes | 18:35.35 |
| | I believe that sounds like a good idea based upon what I am seeing here | 18:35.52 |
| Robin_Watts_ | Certainly the correction makes sense for very light tones. | 18:36.00 |
| | And potentially in dark tones we'd like the same kind of thing done, but with 'distance between white pixels'. | 18:36.41 |
| mvrhel | right | 18:36.53 |
| ray_laptop | Robin_Watts_: IFF, do_shadows ? | 18:36.57 |
| Robin_Watts_ | No. | 18:37.02 |
| | sorry. let me be clearer. | 18:37.34 |
| ray_laptop | recall that dispersed white dots are _rarely_ visible with inkjet drop sizes | 18:37.36 |
| mvrhel | right | 18:37.43 |
| | so lets just worry about the hightlights | 18:37.53 |
| ray_laptop | mvrhel: agreed | 18:38.02 |
| Robin_Watts_ | I'm not averse to the idea of having a separate option to enable the 'white dot even toning', but that's NOT what do_shadows currently tries to do. | 18:38.15 |
| | To do white dot even toning, we'd need to keep a whole new set of distance measurements. | 18:38.32 |
| mvrhel | lets not worry about that | 18:38.42 |
| Robin_Watts_ | right. | 18:38.47 |
| | So, any feelings about e1 vs e2 or e3? | 18:39.03 |
| mvrhel | so you have an e2 case... | 18:39.05 |
| | and e3 | 18:39.10 |
| | I see more issues below his tounge with e2 and less with e3 | 18:40.31 |
| | all are better in the canine compared to e0 | 18:41.02 |
| | what is the difference code wise? | 18:41.21 |
| | or parameter wise | 18:41.44 |
| ray_laptop | the purple area below the tongue is better with e3 | 18:42.37 |
| mvrhel | right | 18:42.44 |
| | e2 is worse | 18:42.55 |
| | what changed Robin_Watts_ ? | 18:43.06 |
| Robin_Watts_ | The differences here are to do with the scaling applied to the ets correction. | 18:43.13 |
| mvrhel | one of the magic numbers? | 18:43.34 |
| ray_laptop | it's all FM | 18:43.48 |
| Robin_Watts_ | e1 is the code as it came to me. We calculate r = actual distance - expected distance | 18:44.00 |
| | then we futz with that for a bit, and then use it as a bias. | 18:44.18 |
| ray_laptop | (FM does NOT stand for Frequency Modulation screening) | 18:44.18 |
| Robin_Watts_ | how we futz with that is what e does. | 18:44.34 |
| | e 0: set r to 0. | 18:44.43 |
| | e 1: if (r > 0) r>>=3; | 18:44.53 |
| | e2: use r as is. | 18:45.11 |
| | e3: r >>= 3; | 18:45.17 |
| | So assuming Raph had a clever undocumented reason for his code, we should expect e1 to be best. | 18:45.48 |
| ray_laptop | but we _seem_ to like e3 better (slightly) | 18:46.06 |
| Robin_Watts_ | I *think* I like e3 best, but it's a very close thing. | 18:46.44 |
| | Given that e3 involves shifting down, and has fewer white spots, I think that might add credence to the idea that the white spots are caused by overflow. | 18:48.33 |
| | But anyway, I think we should reserve judgement on e1/2/3 until we have those spots solved. | 18:49.09 |
| | because those are probably the overriding factor in the differences, would you agree? | 18:49.31 |
| mvrhel | I agree | 18:51.16 |
| Robin_Watts_ | OK. Then we have the 2 random noise ones. | 18:51.31 |
| | Both are horrid. | 18:51.38 |
| ray_laptop | just for reference, the red (darker orange) stripes on the nose are original RGB color 0.599609 0.149902 0, then the darker (what looks near black on top) is RGB 0.300049 0 0 | 18:52.18 |
| Robin_Watts_ | There is scope for us to wind the random noise down. | 18:53.32 |
| mvrhel | Robin_Watts_: I agree about the use of random. I am not sure if its use would be ok near certain transitions as mentioned in Raph's paper | 18:54.00 |
| ray_laptop | Robin_Watts_: and maybe look at a better 'tm' matrix | 18:54.02 |
| | (for the r1 case) | 18:54.11 |
| mvrhel | e.g. near 1/2 | 18:54.38 |
| | 1/4, 1/3 | 18:54.45 |
| Robin_Watts_ | mvrhel: What the paper suggests (and the code implements) is that the scaling applied to the random noise is chosen for each pixel based upon the source intensity value. | 18:55.03 |
| mvrhel | right. | 18:55.30 |
| Robin_Watts_ | and indeed, the scaling is larger near rational transitions | 18:55.38 |
| mvrhel | ok | 18:55.43 |
| | so it is doing that with this | 18:55.47 |
| Robin_Watts_ | but all the scalings are done by shifts. | 18:55.50 |
| mvrhel | and the diff between r1 and r2 here? | 18:55.59 |
| Robin_Watts_ | so it's a somewhat blunt instrument. | 18:56.01 |
| ray_laptop | which is a rather heavy hammer | 18:56.04 |
| | robin types faster | 18:56.13 |
| Robin_Watts_ | :) | 18:56.16 |
| | and there is an 'overall shift' as well. | 18:56.24 |
| mvrhel | oh. its not like a small bias is added | 18:56.30 |
| | or subtracted | 18:56.37 |
| Robin_Watts_ | No. | 18:56.42 |
| mvrhel | well that could be done a bit better then | 18:56.51 |
| Robin_Watts_ | yes. I think there is scope for experimentation here. | 18:57.03 |
| mvrhel | in its current form though I would suggest it be turned off | 18:57.48 |
| Robin_Watts_ | mvrhel: Right. -r 0 :) | 18:57.58 |
| | do either of you have inkjets that you can drive so that we can do test prints? | 18:58.46 |
| mvrhel | I used to have an hp inkjet that I could drive directly | 18:59.07 |
| | I may have gotten rid of it | 18:59.13 |
| ray_laptop | I think a color chart that showed all of the transitions might help asses the need for r>0 use | 18:59.15 |
| mvrhel | need to check the garage | 18:59.18 |
| ray_laptop | I have an Epson 2200 but it's been 3+ years since I ran it | 18:59.49 |
| mvrhel | and the code that I had to drive it | 19:00.00 |
| Robin_Watts_ | I have a Canon MFP thing, but I'd need to dive into the gutenprint stuff to figure out how to output stuff without it all being redithered etc :( | 19:00.09 |
| mvrhel | right | 19:00.18 |
| ray_laptop | and the 'rinkj' driver outpus to the 2200, iirc | 19:00.24 |
| mvrhel | hold on let me see what I have | 19:00.35 |
| Robin_Watts_ | ok, so I can't palm that off easily on either of you. Rats :) | 19:00.38 |
| ray_laptop | that's what Raph used for testing | 19:00.39 |
| | I'll see if I can fire up the 2200 | 19:00.52 |
| | Epson escape stylus raster format is well understood. at least they give you direct 1:1 input in CcMmYKk | 19:01.56 |
| Robin_Watts_ | I *thought* that the canon here was PCL, but I could be wrong. | 19:02.26 |
| mvrhel | ok | 19:02.54 |
| Robin_Watts_ | and I don't speak PCL in any meaningful fashion. | 19:03.01 |
| mvrhel | I do have an HP GPB10 demo printer that we used to drive directly when I worked with randair | 19:03.23 |
| | need to see if I can actually still run it and get cartridges | 19:03.51 |
| ray_laptop | I should be able to try the 2200 today (replace all of the inks and run several maintenance cycles) | 19:04.01 |
| mvrhel | it is fairly compact and I can bring it to the meeting even | 19:04.10 |
| ray_laptop | the 2200 is fairly bulky (for an inkjet). It prints A3 width | 19:05.08 |
| Robin_Watts_ | ok, well, I'll try to get my canon working too - that way we can have several routes to test, which would be good. | 19:06.35 |
| mvrhel | this thing is 10 years old https://h10057.www1.hp.com/ecomcat/hpcatalog/specs/provisioner/05/C8111A.htm | 19:07.00 |
| Robin_Watts_ | I was thinking some more about the distance measurement thing. | 19:07.26 |
| | And how it needs to change in the presence of multiple levels. | 19:07.46 |
| ray_laptop | OK. | 19:08.38 |
| Robin_Watts_ | For any given greyscale, imagine that intensity dithered over an infinite area. There would be effectively a 'base intensity' with a set of dots every now and then at 'base intensity + 1' | 19:09.15 |
| | And the goal of even toned screening is to ensure that the distance between the +1 dots is even. | 19:10.15 |
| ray_laptop | and to compensate for base_intensity+1 dots, we' need to have some dots at base_intensity-1 | 19:10.33 |
| Robin_Watts_ | ray_laptop: No. | 19:10.44 |
| ray_laptop | is base_intensity a level ? | 19:11.07 |
| Robin_Watts_ | Let's say that intensity i is in the 0 to 1 range. | 19:11.47 |
| ray_laptop | maybe I'm too focused on the transition point (33% and 66% when levels = 4) | 19:12.06 |
| Robin_Watts_ | and the actual levels achievable to us are 0, 1/(levels-1), ... (levels-1)/(levels-1) | 19:12.25 |
| | so when levels=4, we can actually get dots for 0, 0.33, 0.66, 1 | 19:13.02 |
| ray_laptop | Robin_Watts_: OK, except achievable is more like 0 0.50, 0.7, 1 | 19:13.40 |
| Robin_Watts_ | Right, but that'd be hidden in the gamma tables, I'd hope. | 19:14.09 |
| | at least everything in this algorithm assumes that that is the case. | 19:14.38 |
| | So for any given i, we 'round it down' to the achievable level below i. | 19:15.00 |
| ray_laptop | but when you put down a 0.5 dot the expected distance is much greater than if is a 0.33 dot | 19:15.18 |
| Robin_Watts_ | So 0.5 would go to 0.33 - that would be our "base intensity" | 19:15.25 |
| | and an infinite expanse of 0.5 would actually be an infinite expanse of 0.33 with occasional 0.66 dots to bring it up to 0.5 on average. | 19:15.58 |
| | right? So we're either sending 'base level' or 'base level+1'. | 19:16.57 |
| ray_laptop | Robin_Watts_: that's assuming the engine can do "an infinite expanse of 0.33", but we can leave that for later | 19:17.02 |
| Robin_Watts_ | (base level is probably better than base intensity) | 19:17.11 |
| | So in order to "even tone screen" that, we want to ensure that the 'base level+1' dots are evenly spaced. | 19:17.40 |
| ray_laptop | Robin_Watts_: and assuming that we don't want any 0.66 dots until we are above 0.33 desired intensity (which may not be the case) | 19:17.56 |
| Robin_Watts_ | Right, but again that's an assumption of this algorithm. | 19:18.27 |
| | So in order to achieve the even toned screening, we are not interested in "distance since the last dot". | 19:19.18 |
| ray_laptop | Robin_Watts_: OK, but that's why I think we need to improve it | 19:19.20 |
| Robin_Watts_ | We are interested in "distance since the last base_level+1 dot". | 19:19.35 |
| | Which means we'd need to keep separate distance counts for all the different levels. | 19:19.59 |
| | Which sounds like a tall order to me. | 19:20.06 |
| | So, coupling this with what we said earlier about only wanting to apply ETS to highlights I wonder if we should only apply ETS to intensities that fall within the first 'level' band. | 19:21.21 |
| | (Clearly I've scared mvrhel off entirely) | 19:21.51 |
| mvrhel | I am not sure about all of this. In the high lights, which is where I would expect to see ETS have an impact, I would hope that I would see well spaced light dots, not dark dots | 19:21.56 |
| Robin_Watts_ | mvrhel: Right. | 19:22.10 |
| mvrhel | I was saving my comments until you finished | 19:22.11 |
| | in those transition areas, we may end up turning ETS off | 19:22.47 |
| Robin_Watts_ | For a highlight (say 0.1), we'd expect to see mostly 0 dots, interspersed with evenly spaced level 1 dots. | 19:22.53 |
| mvrhel | that is in the midtones and beyond | 19:22.56 |
| Robin_Watts_ | My contention is that we should consider turning off ETS for any intensity that would fall on level 1 or above anyway. | 19:23.37 |
| ray_laptop | probably on inkjets the 'compression' of levels will make level 2 and even 3 dots not be very visible in field of level 1 dots | 19:24.09 |
| mvrhel | Robin_Watts_: yes I agree | 19:24.28 |
| Robin_Watts_ | ray_laptop: They may not individually be visble, but they will have the effect of darkening the overall field, which is what we want right? | 19:24.54 |
| ray_laptop | so e0 distribution for dots above level 1 is probably OK. May not look so on the display, but OK on paper | 19:25.00 |
| Robin_Watts_ | (I mean, you might not be able to exactly pinpoint where the darker dot was as it will 'spread' into the surrounding ink, but there WILL be a darker region) | 19:25.38 |
| | OK. | 19:25.43 |
| ray_laptop | I have to run an errand. BBIAW. I'll check the logs later. Thanks for letting me chime in. | 19:26.01 |
| Robin_Watts_ | so it sounds to me like we're all vaguely in agreement then. | 19:26.01 |
| ray_laptop | Yes, as long as Max is looking at paper for multi-level and NOT the display (as I think he was) | 19:26.36 |
| Robin_Watts_ | And this is where the 0.55/0.6 thing might start to make sense. | 19:27.15 |
| ray_laptop | and if we ignore the issue of printers that can't print runs of level 1 dots | 19:27.18 |
| mvrhel | ok. so I am going to grab some lunch. Robin_Watts_ do you want to write up what we want to do and our thoughts on all of this? | 19:27.53 |
| ray_laptop | That's the problem that cust 240 ran into (Epson and a few others had a constraint) | 19:28.02 |
| mvrhel | of course it is getting late for you | 19:28.04 |
| Robin_Watts_ | mvrhel: Not really :) | 19:28.07 |
| mvrhel | hehe | 19:28.10 |
| | Ok. I can try to do it | 19:28.18 |
| ray_laptop | bbiaw. | 19:28.26 |
| Robin_Watts_ | mvrhel: OK, that would be good, thanks. | 19:28.28 |
| mvrhel | no worries. thanks for leading the charge | 19:28.38 |
| Robin_Watts_ | I reckon we should rip the white skipping stuff out personally. | 19:28.52 |
| ray_laptop | Robin_Watts_: and thanks for adding in the comments!!! | 19:28.55 |
| mvrhel | I will send something out to you and ray | 19:29.05 |
| Robin_Watts_ | It's all very well skipping runs of white pixels, but the distance calculations need to be maintained. | 19:29.26 |
| ray_laptop | Robin_Watts_: well, if we can do it, that can make a big performance difference | 19:29.28 |
| Robin_Watts_ | and they aren't. | 19:29.30 |
| | ray_laptop: I'm not averse to skipping white sections efficiently, but I'd like us to skip them CORRECTLY :) | 19:30.02 |
| ray_laptop | Robin_Watts_: agreed. | 19:30.19 |
| mvrhel | bbiaw | 19:30.41 |
| | ok so the productivity power tools are for VS 2010 | 20:48.50 |
| | ok found it in the VS extensions | 20:53.58 |
| | RockMargin | 20:54.03 |
| | and that worked | 20:54.44 |
| | much better | 20:55.03 |
| | got a margin guide extension too | 21:14.58 |
| sebras | g'night. | 23:09.28 |
| ray_laptop | mvrhel: thanks for capturing the info from our 'chat' earlier. I emailed a couple of comments.... | 23:18.38 |
| Ch3rryC0ke | Hey there-- I'm using mupdf in an app where I want to print PDFs. Is there a way to turn off anti-aliasing when rendering pages for printing? | 23:35.39 |
| | Or are there any other best practices for using mupdf and printing? I'm finding that when printing text, even when rendering a very high res image of a page, the text looks blurry/jaggy when printing. | 23:36.10 |
| | Forward 1 day (to 2012/11/08)>>> | |
IRC Logs