| | <<<Back 1 day (to 2011/09/18) | 2011/09/19 |
| cryptopsy | lots of earthquakes lately | 00:16.45 |
| sebras | tor8: and now there's another patch on my branch. this one reducing mupdf memory leaks from 1.5Mbyte to 20Kbyte when viewing a simple text PDF -- we were leaking the entire display list, links, text and document title it seems. | 00:51.53 |
| | that's it for me today, good night! | 00:52.14 |
| mvrhel2 | hi Robin_Watts | 01:01.56 |
| | hiking was good. looking forward to chatting with you tomorrow about the planar/chunky stuff | 01:02.42 |
| | sounds really good | 01:02.47 |
| cryptopsy | i accidentally executed a pdf file and there are all sorts of filees that have been produced with strange names | 01:04.25 |
| | -rw-r--r-- 1 root root 0 Sep 18 20:57 ??@M??? | 01:04.28 |
| | could there have also been delete operations, or operations exceeding the scope of the folder? | 01:04.43 |
| kens | Hi chrisl, did you get Marcos's spam yet ? | 06:58.49 |
| chrisl | Hi kens, what the 345 changes in bugzilla? | 06:59.48 |
| kens | That's hte ones yes. I get some of them more than once, so its nar 400 emails for me. | 07:00.11 |
| chrisl | You'll get one if the bug is assigned to you, and one through the mailing list. | 07:00.43 |
| kens | EWxactly. | 07:00.51 |
| | Still wading through them :-( | 07:01.03 |
| chrisl | I doubt any are mine, but I'll look through them quickly | 07:01.49 |
| kens | I'm just looking at them to make sure that they are just Marcos saying he's closing them, but ti still takes a long time. | 07:02.21 |
| djpk | hello | 08:27.54 |
| | About mupdf. Is it a way to use it embedded into chromium ? | 08:28.07 |
| kens | You'd have to write the plug-in yourself | 08:28.39 |
| Lafriks | Hi Robin_Watts | 08:52.27 |
| kens | Robin is probably not online yet. | 08:52.47 |
| Lafriks | oh ok | 08:53.42 |
| | maybe you know | 08:55.26 |
| | is it possible to clone his git://git.ghostscript.com/user/robin/mupdf.git/.git repository or is it only accessible from web? | 08:56.12 |
| | somehow I cant manage git to clone it | 08:56.37 |
| kens | It should be possible to clone it I would think, but I am not a Git expert | 08:56.42 |
| | Robin shuold be around in 30-60 minutes | 08:56.57 |
| Lafriks | ok, thanks | 08:57.16 |
| Robin_Watts | I'm here. | 08:59.18 |
| | It's exactly possible to clone it, just use that URL. | 08:59.30 |
| | I'll be back properly in an hour. | 09:00.13 |
| | oh, I mean the http version of that URL. | 09:01.07 |
| kens | chrisl we were both correct abou thte type 3 fallback. It stays vector providing the input is type 3, but goes to bitmap for other font types. So not an option in this case. | 09:06.16 |
| | Looks like my stripping routine works, so I'm going to move to a synthetic $Blend now. | 09:06.35 |
| Lafriks | Robin_Watts: strange, I get "fatal: http://git.ghostscript.com/user/robin/mupdf.git/.git/info/refs not found: did you run git update-server-info on the server?" | 09:12.51 |
| | if I use git protocol I get "fatal: The remote end hung up unexpectedly" | 09:13.42 |
| chrisl | kens: shame about the type 3 idea, but as you're making good progress, it's not a huge issue. | 09:28.39 |
| kens | Agreed, if only I could do simple arithemtic as well.... | 09:29.02 |
| Robin_Watts | Lafriks: We disable git access. | 10:32.20 |
| | because no one other than us can commit. | 10:32.27 |
| | We commit using ssh: | 10:32.32 |
| | http: should work though. Let me look. | 10:32.43 |
| | Try now ? | 10:39.59 |
| tor8 | Robin_Watts, Lafriks: it could be because it's not a bare repository. try cloning without the trailing /.git | 10:44.56 |
| | if that doesn't work, it's probably a setup issue. with git:// access you need to have a file git-daemon-export-ok in your git, and for http access you need to set up a hook to run git-update-server-info | 10:45.54 |
| Robin_Watts | I think it should work now. | 10:53.50 |
| sebras | tor8: let me know what you think about the patches, I'll be lurking here proper today... | 11:34.31 |
| tor8 | sebras: s/expectedat/location/ and they're good to go | 11:37.51 |
| sebras | tor8: sweet, will fix when I return home this evening. | 11:39.48 |
| tor8 | Robin_Watts: rename xps_context to xps_document, s/ctx/doc/ so we don't get fz_free(ctx->ctx, foo)? | 11:40.40 |
| Robin_Watts | tor8: Will do. | 11:41.39 |
| tor8 | ugh, got customer bugs on ghostxps... highlighting the limitations of the gs graphics library :( | 11:42.44 |
| | images with funky colorspaces and bit depths and transparency are all wonky in ghostxps but work as expected in muxps | 11:43.32 |
| Robin_Watts | http://ghostscript.com/~robin/Enc1.jpg | 11:50.59 |
| | Life would be much easier if people supplied boards in a form ready to use, rather than me having to spend hours making enclosures, etc. | 11:51.51 |
| | http://ghostscript.com/~robin/Enc2.jpg | 11:56.04 |
| Lafriks | Robin_Watts: it is working with http now, | 11:58.22 |
| | thanks | 11:58.24 |
| Robin_Watts | cool. | 11:58.30 |
| jrm222 | thanks tor8 | 12:12.45 |
| kens | chrisl I just realised that bug #692515 is assigned to you. Hope you don't mind me closing it. | 12:56.06 |
| chrisl | kens: no, I was going to assign to you anyway. | 12:58.58 |
| Lafriks | Robin_Watts: I don't know how exactly your new memory allocation works but is there a way to move fz_context struct out of fitz.h file to context.c? | 13:09.21 |
| Robin_Watts | Not currently. | 13:09.43 |
| Lafriks | looks like I will have to create new struct that will hold freetype library pointer than | 13:12.16 |
| | and add pointer to that struct context struct | 13:12.49 |
| Robin_Watts | Yes, that's generally the way it should be done. | 13:13.13 |
| | The definition of the context struct is global (i.e. everything understands the contents of the context). | 13:13.38 |
| | But those contexts should mostly be pointers to structures that can be private to different areas of the code. | 13:13.58 |
| | In some cases, if it's just a pointer you need to store, you can store that direct in the context. | 13:14.17 |
| | Gah. Companies supplying toolkits for linux is all very well, but it's dependency hell trying to install them. | 13:17.41 |
| Lafriks | yes I understand that but in this case it will be structure that will hold just pointer and refcount but as it is external library pointer than most probably best is to keep it in different struct | 13:18.31 |
| | Robin_Watts: is fz_context_clone used somewhere or is it just for future use? | 13:20.50 |
| Robin_Watts | It's for future use. | 13:21.02 |
| | The theory is that if you have different threads, you'll clone the context. | 13:21.26 |
| | Stuff that can safely be shared (like the allocator) will stay the same. Stuff that has to change will be reinited. | 13:21.47 |
| ray_laptop | yet another visit to cust 532. At least things are going pretty well, but now they want to use their buffers (a'la band_donor approach). Going up there to talk them through it. | 13:53.53 |
| | I _really_ need to spend a bit of time on 'genpat' to get the stochastic dither to generate multi-level thresholds. Their ordered dither thresholds are pretty bad (IMHO) | 13:55.18 |
| Robin_Watts | ray_laptop: Fun fun fun | 14:16.18 |
| ray_laptop | I saw that mvrhel is all charged up to dive back into the planar vs.chunky performance again after soaking up the great outdoors | 14:17.23 |
| | nothing like a weekend in the woods away from all internet and phone to give you a recharge | 14:17.52 |
| Robin_Watts | Sounds horrible. | 14:18.54 |
| ray_laptop | the three level threshold array to 2-bit halftone is looking pretty good. Someday we'll have to look at fixing the halftoning in ghostscript so we can handle that (and use threshold arrays as the basic definition) | 14:19.56 |
| | but I'm wondering if we need to also be able to handle painting from just tiles so that we can support non-monotonic patterns | 14:21.05 |
| | (not that I've ever really seen them used) | 14:21.35 |
| henrys | ray_laptop:stochastic halftones on a color laser? | 14:39.03 |
| ray_laptop | henrys: yes, with minimum dot size and cluster growing | 14:47.27 |
| henrys | chrisl:do you think freetype for the languages can get a bit more priority before the next staff meeting, I think it would be good to get some progress on that. tor's response about boldening sort of reminded me about that. | 14:52.56 |
| | Robin_Watts and I are ready to pounce when mvrhel2 arrives ;-) | 14:54.46 |
| chrisl | henrys: sure, I'll spend some "proper" time on it soon. | 14:59.45 |
| henrys | just when we try to get the bug number down to 0 we get 10 xps bugs in one day ... sigh | 15:00.33 |
| Fandekasp | hi | 15:08.52 |
| | I have a question about mupdf | 15:08.59 |
| | how can I open it in fullscreen, or make it fullscreen once opened ? | 15:09.21 |
| Fandekasp | is using sabayon xfce4 | 15:09.31 |
| Robin_Watts | Woo Hoo! Just booted the board in the enclosure. | 15:11.05 |
| kens | excellent | 15:11.39 |
| Robin_Watts | Now I need to figure out a) what to use as a boot device, b) what to put on it. | 15:12.15 |
| Fandekasp | I can see here http://bugs.ghostscript.com/show_bug.cgi?id=692165 that there is a patch for full-screen, but I wonder if it has been integrated. the z keymap already exist | 15:17.40 |
| sebras | Fandekasp: no, it hasn't. but the bug is still open. :) | 15:18.48 |
| Fandekasp | oh ok | 15:19.13 |
| Robin_Watts | henrys: At the meeting we mentioned company M- You were going to chase them up? Did you need anything from me ? | 15:19.17 |
| Fandekasp | hmm I can give a option a -r dpi. As I use it in a script, that's enough I guess | 15:20.25 |
| sebras | Fandekasp: I may get around to it this week, I'm not sure how tor8 views this patch though? | 15:20.39 |
| Fandekasp | That'd be great :D with that, mupdf is definitively my favorite pdf viewer hehe, I like the vim keymaps | 15:21.15 |
| henrys | Robin_Watts:no I am going through the meeting list now. I'll send out a followup for each item, apparently I missed the last meeting followup I see the draft sitting in my email box. | 15:23.14 |
| Lenhix | Hello. I'm developing a (PHP) web page for users to upload TXT/TIFF/PDF files which are gonna be sent as faxes by my Asterisk PBX. I've been told gs(1) can be used to convert those to TIFF (which is what Asterisk needs for faxes). Is that right? Am I in the wrong channel? | 15:27.41 |
| kens | GS can output TIff, yes | 15:28.04 |
| | You should probably use the new tiffscaled device | 15:28.18 |
| | Not TIIF or TXT input though, only PDF or PostScript | 15:28.42 |
| Lenhix | Oh. So that's a part of the solution XD. | 15:34.02 |
| sebras | Fandekasp: We're happy you like it. | 15:37.26 |
| Fandekasp | :) | 15:39.11 |
| Lenhix | What could be wrong with this: http://pastie.org/2558189. Bad formatting in the original file? And: any suggestions on how to convert TXT to TIFF? I've read there is mpage, enscript, a2ps. | 15:41.12 |
| kens | First, try using a recent version of Ghostscript, that's ancient | 15:41.48 |
| | Current version is 9.04 | 15:42.00 |
| Robin_Watts | Also the command issued there appears to be "/usr/bin/gs /usr/bin/gs ..." which isn't going to give good results :) | 15:43.33 |
| Lenhix | ¿? :S | 15:44.28 |
| Robin_Watts | Look at lines 1 and 2 in your paste. | 15:44.47 |
| Lenhix | Oh. My bad when pasting. | 15:44.50 |
| Robin_Watts | Ah, ok. | 15:45.00 |
| Lenhix | Seems it's the PDF. Tried with another one and went ok. About updating gs(1), I'm tied to this CentOS 5.6, wich latest ghostcript package is 8.70. | 15:46.53 |
| kens | You don't need a package, you can install it yourself. | 15:47.20 |
| | From source. | 15:47.26 |
| | Also the version you appear to be using is 8.15 whihc is older than 8.70 | 15:47.48 |
| | I would strongly advise upgrading. | 15:47.53 |
| Lenhix | I'll have to discuss that with boss. PBX is already on production state. | 15:48.37 |
| | Well. At least updating to 8.70 made it work with that last PDF. | 15:58.35 |
| | Now, gotta try a2ps + gs. | 15:58.56 |
| kens | Buggy PDFs work better with more recent versions. | 15:59.00 |
| Lenhix | Sure. But I'm not boss yet :(. | 16:00.45 |
| Robin_Watts | mvrhel2: You here? | 16:03.09 |
| mvrhel2 | hi Robin_Watts: I am | 16:03.17 |
| Robin_Watts | Did you read the irc logs? | 16:03.27 |
| mvrhel2 | I skimmed todays | 16:03.36 |
| | let me review the other days | 16:04.11 |
| | looks like the ideas were flying left and right on friday | 16:14.35 |
| Robin_Watts | yeah. | 16:15.24 |
| mvrhel2 | so I do have one fundamental question. how do rops work properly once you have halftoned. forget for a second about CMY(K) | 16:15.37 |
| Robin_Watts | The results of the halftones are ropped. | 16:15.51 |
| | That is, the cmyk halftoned results are read back, converted to rgb, the rop is done, then they are converted back to cmyk. | 16:16.35 |
| | Ropping the 'contone' values would mean doing all the rendering in contone, and then just halftoning the final results. henrys claims that would be too slow. | 16:17.37 |
| mvrhel2 | yes. I agree that would be slower | 16:17.49 |
| | what I am having trouble with is the loss of a proper conversion from RGB to CMYK | 16:18.33 |
| | contone | 16:18.37 |
| Robin_Watts | I have to confess it has it's attractions to me; just do everything in contone, then use your fast image rop code to halftone it at the end. | 16:18.37 |
| | I believe that we have effectively lost that already. | 16:18.48 |
| mvrhel2 | ? | 16:19.06 |
| Robin_Watts | Whenever rops are used, the cmyk -> rgb and rgb->cmyk steps are not color managed. | 16:19.17 |
| mvrhel2 | ok | 16:19.24 |
| | hold on one sec though | 16:19.29 |
| | PCL is all defined in RGB | 16:19.41 |
| | if I do a proper conversion from RGB to CMYK and halftone (ignore ROPS for a sec) then I am good | 16:20.05 |
| | when I say proper I mean define a destination ICC profile | 16:20.16 |
| Robin_Watts | Yes. | 16:20.18 |
| mvrhel2 | now I have this halftoned CMYK value | 16:20.30 |
| | and I have a ROP operation to perform with it | 16:20.41 |
| | I really only have a few color values to worry about converting from CMYK to RGB | 16:21.23 |
| | since it is hafltoned | 16:21.29 |
| | where I apply the ROP | 16:21.39 |
| kens | I#'m off now, night all | 16:21.41 |
| Robin_Watts | Yes. | 16:21.45 |
| mvrhel2 | and do a conversion back | 16:21.48 |
| | why is that an issue? | 16:21.55 |
| Robin_Watts | It may not be. | 16:22.22 |
| | So maybe I'm wrong to say that color conversion has gone out the window. | 16:22.39 |
| mvrhel2 | The conversion that is done from CMYK hafltoned to apply the ROP is different than the ICC conversion that should be done before halftoning (or at least it should be) | 16:23.18 |
| Robin_Watts | With two level halftones (so things are either on or off) then you're always dealing in saturated components, so you may be OK. | 16:23.19 |
| mvrhel2 | yes | 16:23.26 |
| | I need to get a better understanding of the type of operations that ROPs can be doing | 16:23.44 |
| Robin_Watts | With 4 level halftones, you'd have a different matter I think. | 16:23.44 |
| mvrhel2 | perhaps, but lets start with 2 level | 16:24.02 |
| | and go from there. | 16:24.06 |
| Robin_Watts | still trying to grok what you said... about "The conversion that is done..." | 16:24.15 |
| mvrhel2 | Robin_Watts: so we use the ICC CMM to take contone RGB from PCL and go to contone CMYK and then we hafltone | 16:24.51 |
| | once the data is halftoned, we will be doing something different to get out of CMYK to RGB | 16:25.38 |
| | and back to CMYK | 16:25.45 |
| Robin_Watts | Right, yes. | 16:25.46 |
| mvrhel2 | or, we could just come up with ROP operations to do in CMYK | 16:25.59 |
| Robin_Watts | The pre-halftoned step is color managed. The post halftoned stuff isn't. | 16:26.01 |
| mvrhel2 | directly | 16:26.01 |
| | right. the goal of the post halftoned stuff is to get us the best approximation to the contone ROP operations | 16:26.19 |
| henrys | The customer was quite clear they went to 4 bit cmyk and then did the rops in cmyk space. It seems like voodoo to me but that's what they said. | 16:26.24 |
| Robin_Watts | What operations can be done with rops? A rop is a bitwise operation with 3 inputs. | 16:26.25 |
| mvrhel2 | that is where I would really like to see what the ROP operations could be | 16:26.26 |
| | yes, I am thinking doing them in CMYK too | 16:26.40 |
| Robin_Watts | f(d,s,t). | 16:26.40 |
| | d = destination pixel, s = source pixel, t = texture pixel. | 16:26.44 |
| | Hence there are 256 (=2^8) rops. | 16:26.59 |
| mvrhel2 | no hence, you need to fill in the blanks :) | 16:27.11 |
| henrys | well halftoned space is the voodoo cmyk is not surprising. | 16:27.13 |
| Robin_Watts | When you 'rop' contone values, it's still bitwise. | 16:27.18 |
| | mvrhel2: OK. | 16:27.29 |
| mvrhel2 | I have pencil and paper out... | 16:27.46 |
| Robin_Watts | Write yourself a truth table out (or think of one). | 16:27.50 |
| | 3 inputs, 1 output. | 16:27.55 |
| mvrhel2 | ok | 16:28.52 |
| Robin_Watts | There are 8 possible combinations of inputs (000, 001, 010, 011 etc) | 16:28.52 |
| henrys | do you want the pages from the pcl manual - it has an example easily followed. | 16:28.52 |
| | ? | 16:28.53 |
| Robin_Watts | Those inputs are the same for every rop operation. | 16:29.09 |
| mvrhel2 | henrys: yes that would be nice | 16:29.33 |
| Robin_Watts | But the outputs for each of the lines can be either 0 or 1 according to the different rop in use. | 16:29.41 |
| mvrhel2 | Robin_Watts: so where do the contone values come in? | 16:30.01 |
| Robin_Watts | Ignore contone for now. | 16:30.07 |
| mvrhel2 | and the rop is the function f | 16:30.20 |
| Robin_Watts | Just think of rops as working on 1 bit things. | 16:30.22 |
| | Yes. | 16:30.24 |
| mvrhel2 | ok | 16:30.27 |
| Robin_Watts | So, there are 8 possible output bits that vary. | 16:31.22 |
| | Which means there are 2^8 = 256 possible rops. | 16:31.32 |
| | yes ? | 16:31.39 |
| mvrhel2 | hmmm | 16:32.02 |
| | I see I have a function f | 16:32.08 |
| | that has 3 inputes | 16:32.12 |
| | that are bilevel | 16:32.20 |
| | but f has not been defined for me | 16:32.37 |
| Robin_Watts | Right. | 16:32.39 |
| mvrhel2 | and is the rop operator | 16:32.42 |
| Robin_Watts | Indeed. | 16:32.45 |
| | Let me just do a diagram. | 16:33.01 |
| mvrhel2 | but I could make f be anything | 16:33.04 |
| | it could be a random number generator | 16:33.25 |
| Robin_Watts | No. | 16:33.39 |
| mvrhel2 | :) | 16:33.42 |
| henrys | if you can wait for the manual I think it will save you drawing a diagram. | 16:33.45 |
| Robin_Watts | Any given rop can be drawn as a 3 input, 1 output truth table. | 16:34.09 |
| mvrhel2 | oh | 16:34.31 |
| Robin_Watts | The exact values in the output column are defined by (or, if you prefer, define) the rop in use. | 16:34.31 |
| mvrhel2 | I see what you are saying | 16:34.37 |
| | and the output is binary also | 16:34.44 |
| Robin_Watts | Hence there are 256 possible rops. | 16:34.45 |
| | Yes. | 16:34.47 |
| mvrhel2 | with 8 bits | 16:34.49 |
| Robin_Watts | Yes. | 16:34.54 |
| mvrhel2 | so 256 possible options | 16:34.55 |
| Robin_Watts | Ye.s | 16:34.59 |
| mvrhel2 | gotcha. no random generating rops :) | 16:35.13 |
| Robin_Watts | rop(0), is f(d,s,t) = 0 | 16:35.21 |
| | rop(255), is f(d,s,t) = 1 | 16:35.36 |
| mvrhel2 | wait | 16:35.48 |
| Robin_Watts | rop(0xF0) is f(d,s,t) = d | 16:35.48 |
| mvrhel2 | how is the operator rop(x) related to f(d,s,t) | 16:36.17 |
| Robin_Watts | Take the output bits, arrange them into a byte, and that's the number 'x'. | 16:36.40 |
| mvrhel2 | ok | 16:36.45 |
| henrys | starting on page 77 section 5 - 13 | 16:37.25 |
| mvrhel2 | got the email | 16:37.51 |
| henrys | see they specifically discuss rops in cmy space ... | 16:38.17 |
| Robin_Watts | I found the PCL manual 'unhelpful'. | 16:38.23 |
| | Damn. I have to go fetch Helen from the station. | 16:38.56 |
| mvrhel2 | ok. I will be here when you return | 16:39.06 |
| Robin_Watts | I have an explaination of rops written up in the gdevrop.h file comments. | 16:39.17 |
| mvrhel2 | curious about where contone fits in here through | 16:39.23 |
| | though | 16:39.26 |
| Robin_Watts | Contone doesn't. | 16:39.30 |
| mvrhel2 | ok I will look at that and the manual | 16:39.38 |
| Robin_Watts | Basically for contone, you take the contone values as bytes, and then do the same bitwise operations on them. | 16:40.08 |
| mvrhel2 | I had thought rops had to be done in contone RGB | 16:40.12 |
| Robin_Watts | So each bit of 'd' is combined with the equivalent bit of 's' and 't'. | 16:40.33 |
| mvrhel2 | each bit of the contone data? | 16:40.45 |
| Robin_Watts | Yes. | 16:40.49 |
| mvrhel2 | gawd | 16:40.53 |
| henrys | yes but the customer claims you can get a sufficient approximation with halftoned data. | 16:41.02 |
| mvrhel2 | what a weird opertaor | 16:41.06 |
| | ok | 16:41.14 |
| henrys | further if we are stuck with contone I don't think we can reach the memory goal. | 16:41.25 |
| mvrhel2 | henrys: yes. we need to get out of contone | 16:41.40 |
| | I want to look at this a bit more | 16:41.54 |
| henrys | Robin_Watts:were you looking at the color pcl manual? | 16:42.08 |
| | not the greatest verse I've read but it seems to explain everything. | 16:42.30 |
| Robin_Watts | henrys: I can't honestly remember. | 16:42.31 |
| | I looked at 2 I think. | 16:42.43 |
| | mvrhel2: It works for 'not' type operations (inverse) | 16:42.58 |
| mvrhel2 | yes | 16:43.12 |
| Robin_Watts | but it gets very wierd if you 'orr' non saturated things together. | 16:43.24 |
| | I have to go. | 16:43.27 |
| mvrhel2 | ok ttyl | 16:43.34 |
| Robin_Watts | bb in about 60-90 mins. | 16:43.40 |
| henrys | mvrhel2:how was camping? | 16:45.14 |
| mvrhel2 | It was nice. That was the first time I did any back country stuff. Had to filter my water carry the tent etc | 16:45.40 |
| setmeaway | i build gs with rasterop enabled. then do gs rasterop for any postscript document implicitly? | 16:45.50 |
| mvrhel2 | the olympics are quite isolated. | 16:46.13 |
| | ran into very few people | 16:46.22 |
| henrys | setmeaway:there are documented gs (not adobe) operators for pcl rops and transparency, yes. | 16:46.39 |
| | mvrhel2:most camping in my area is a zoo - too popular. | 16:47.07 |
| mvrhel2 | yes. that is the way it is here in the cascades. the olympics you have to take a ferry and it is about 3 hours away from seattle | 16:47.35 |
| | at least where I went | 16:47.41 |
| | apparently though, the north cascades here, is one of the most isolated national parks | 16:48.15 |
| | I have not been up there yet | 16:48.22 |
| | maybe next year | 16:48.30 |
| | but there are brown bears up there | 16:48.40 |
| | only black bears in the olympics | 16:48.47 |
| henrys | I wouldn't worry about rops right now the important thing is to get the planar foundation in place and hopefully have a performance improvement. | 16:53.04 |
| mvrhel2 | henrys: yes. you know, looking at these what these operations do, do you ever have to perform these on big swaths of varying areas? | 16:54.23 |
| | how are they implemented in the code? | 16:54.50 |
| henrys | you will see throughout the graphics library all sorts of optimizations for rops and transparency. But when they are actually done they are done in device space - if it isn't contone rgb then the results are approximate. The wtsimdi device supported a contone buffer with post pipeline halftoning exactly to support rops. It's too slow and memory intensive to meet this customers needs. | 16:57.49 |
| mvrhel2 | I am trying to understand if the inputs d, s and t are typically varying spatially across some region and applied in a bit wise fashion | 16:58.40 |
| | to do the operator | 16:58.49 |
| henrys | of course get_bits is the star of the show | 16:58.56 |
| mvrhel2 | yes, | 16:59.10 |
| henrys | yes for example the xor operator is used to erase large areas - stuff like that. | 16:59.33 |
| mvrhel2 | hmm these operations would seem to be prime for SSE2 accelaration | 17:00.46 |
| setmeaway | henrys thanks | 17:00.58 |
| henrys | but by and large I would say the areas are single colors. | 17:01.04 |
| mvrhel2 | ok | 17:01.09 |
| | for a source? | 17:01.13 |
| henrys | image roping is rare. | 17:01.16 |
| mvrhel2 | and the texture? | 17:01.17 |
| henrys | texture just means pattern for all intents and purposes. | 17:01.37 |
| mvrhel2 | ok | 17:01.46 |
| | let me read through a couple things | 17:04.00 |
| | to avoid asking too many dumb questions | 17:04.20 |
| henrys | a popular usage is clipping there are only rectangular clips in pcl so you can use an operator and draw a complex path and then "not" the destination to erase stuff. | 17:05.37 |
| | chrisl:be careful with these changes to the ufst - it is a private repository, we have to be careful patches don't end up on any public email list. | 17:11.22 |
| | it's pretty easy to throw something out on gs-bugs and not realize it. | 17:12.03 |
| | mvrhel2:oh crap almost forgot spoke with mergui at the show he'd like you to ping guillaume to see if there is anything he needs, maybe what is the Adobe PDF printing solution doing that we aren't doing so as well. | 17:14.38 |
| mvrhel2 | oh. ok. I will send him something today | 17:15.23 |
| Lafriks | Robin_Watts: are you here? | 17:21.30 |
| mvrhel2 | ok. I sent him an email henrys | 17:22.14 |
| henrys | thanks mvrhel2 | 17:28.20 |
| Lafriks | Robin_Watts: I have cleaned up and made patch that could be applied to your mupdf.git repository on failing_allocs head | 17:35.14 |
| | http://www.nix.lv/mupdf/0001-vs2010-support.patch | 17:35.17 |
| | http://www.nix.lv/mupdf/0002-context-struct-changes.patch | 17:35.33 |
| | http://www.nix.lv/mupdf/0003-context-usage-error-freetype.patch | 17:35.55 |
| | I have not still tested this one in threaded enviroment but it should be working | 17:37.16 |
| | I'm not sure if I did everything correct with memory allocation in 2nd patch but I would like to hear your comments | 17:39.14 |
| Robin_Watts | I'm back and I've just read the logs. | 18:00.17 |
| | henrys, mvrhel2: I thought the 'image' case would be rare with rops too, but that's exactly the case that's slowing down the file that we looked at. | 18:00.47 |
| mvrhel2 | Robin_Watts: so how are rops implemented in the code | 18:01.07 |
| Robin_Watts | It's a mono image that gets 'ropped' onto the page in a halftone color. | 18:01.12 |
| | Also, I've seen henrys make this assertion about rops being used for clipping with a 'not' operation before. | 18:01.58 |
| | but I don't see how that's possible. | 18:02.09 |
| | I can see how you'd use rops to achieving clipping, but I don't think 'not' comes into it. | 18:02.40 |
| | Lafriks: I'll try to find time to have a look, thanks. | 18:03.09 |
| | Could you possibly open a bugzilla bug, and attach those patches? Then I can assign it to me, and it won't get forgotten. | 18:03.30 |
| | mvrhel2: Right... How are rops implemented in the code... | 18:03.45 |
| mvrhel2 | Robin_Watts: so I *think* I understand how the rops conceptually work. but I am curious what the step of operations are to implement them in the code | 18:03.53 |
| | that is, lets say I do have a source contone image | 18:04.12 |
| Robin_Watts | The key device operation is 'strip copy rop'. | 18:04.18 |
| mvrhel2 | and I have some bits already drawn in | 18:04.18 |
| Robin_Watts | However you render stuff it ends up with a call to strip copy rop. | 18:04.44 |
| | (For instance, in the case where we had a mono image being ropped onto the page, the image code would go to fill_rectangle, and that would magically end up calling strip_copy_rop.) | 18:05.30 |
| | Strip_copy_rop then looks at the rop being used; it can spot certain special cases (like, 'it doesn't use D' at all etc) and sometimes call other routes through the code. | 18:06.24 |
| mvrhel2 | fun, the clist has a strip_copy_rop | 18:06.56 |
| Robin_Watts | Otherwise, it calls 'getbits' to get the current output. | 18:06.59 |
| mvrhel2 | looks like some cmyk stuff in there | 18:07.03 |
| Robin_Watts | Then it 'expands' the source and texture (if they are used, and they aren't in the right format already). | 18:07.33 |
| | Then it performs the rops. | 18:07.38 |
| | then it plots the result back to the output. | 18:07.49 |
| | The magic (nasty black magic, involving entrails and the ritual murder of many chickens) happens in getbits. | 18:08.26 |
| | In particular the rop code calls getbits and asks for everything to be given to it as rgb. | 18:08.55 |
| mvrhel2 | are you looking at the default strip_copy_rop? | 18:09.02 |
| Robin_Watts | (more specifically as rgb chunky) | 18:09.19 |
| | I'm not looking anywhere. This is from memory. | 18:09.27 |
| mvrhel2 | oh I see /* uses_d * | 18:09.31 |
| | and then does a get_bits_rectangle | 18:09.39 |
| Robin_Watts | indeed. | 18:09.43 |
| mvrhel2 | how does get_bits specify a color space? | 18:10.15 |
| Robin_Watts | In the 'options' word passed in. | 18:10.27 |
| mvrhel2 | ok | 18:10.31 |
| Robin_Watts | What file are you looking at? Let me load the source. | 18:10.33 |
| | (My poor 4Gig machine...) | 18:10.45 |
| mvrhel2 | I am in gdevdrop.c | 18:10.49 |
| | in gx_default_strip_copy_rop | 18:11.00 |
| | so is the get_bits operation returning chunky rgb data? | 18:11.48 |
| Robin_Watts | Yes. | 18:11.56 |
| mvrhel2 | ugh | 18:12.03 |
| Robin_Watts | Look at line 517 | 18:12.30 |
| | For greyscale, (rop_depths <8) it gets greyscale, otherwise RGB. | 18:13.03 |
| | In 8 bit, with no alpha. | 18:13.26 |
| | chunky, a copy of the data (not a pointer to the existing data, if it happened to be in the right format), with standard alignment. | 18:13.52 |
| mvrhel2 | ok. K is a bit problematic in this. | 18:16.28 |
| Robin_Watts | Yes. | 18:16.33 |
| mvrhel2 | but certainly going to chunky is not good | 18:16.46 |
| Robin_Watts | Ignore the chunky thing for now. | 18:16.55 |
| | I have some code locally that tries to avoid it in some circumstances. | 18:17.10 |
| mvrhel2 | where is the ROP operation actually carried out | 18:17.14 |
| Robin_Watts | Line 718. | 18:17.27 |
| mvrhel2 | once we have this chunky copy of the destination | 18:17.30 |
| Robin_Watts | That calls the memory devices 'strip_copy_rop' function (i.e. it's got all it's ducks in a row, got all 3 possible data sources in the same format, and calls a simple routine that does the actual work) | 18:18.20 |
| | See gdevm1.c | 18:19.08 |
| | mem_mono_strip_copy_rop_dev for example. | 18:19.21 |
| | line 49. | 18:19.28 |
| mvrhel2 | what does /* Convert the source and texture to standard format. */ do? | 18:19.33 |
| | line 709 | 18:19.40 |
| Robin_Watts | We ask getbits for the 'd' in 8 bit chunky rgb. | 18:19.55 |
| | In order to simply blast them all together in one fast routine, we need S and T to be in that same format. | 18:20.20 |
| mvrhel2 | gotcha | 18:20.23 |
| Robin_Watts | S and T can be specified in various different ways (bitmaps with palette, pixmaps etc) | 18:20.39 |
| mvrhel2 | so the destination is also put into 8 bit? | 18:20.44 |
| | the copy we get? | 18:20.48 |
| Robin_Watts | Yes. | 18:20.52 |
| | Oh, wait... | 18:21.10 |
| henrys | last I looked at the code you were getting data that was already halftoned when you read from destination. | 18:21.23 |
| Robin_Watts | Let me double check that. | 18:21.40 |
| henrys | I don't see how it could be otherwise. | 18:21.40 |
| Robin_Watts | Yes, I believe the destination is always in 8 bit chunky. | 18:22.50 |
| mvrhel2 | so, where does line 718 call? | 18:23.09 |
| henrys | that is impossible. | 18:23.11 |
| Robin_Watts | henrys: I don't see how the bitdepth of the getbits returns has any bearing on whether it's halftoned or not. | 18:23.31 |
| | Line 718 ends up calling through to somewhere like gdebmr1.c line 49 | 18:24.16 |
| | gdevmr1.c even. | 18:24.23 |
| henrys | fine so it return 1 or 0 in 8 bits? and no other value. | 18:24.53 |
| Robin_Watts | henrys: Yes. | 18:25.02 |
| henrys | and it derived that value from a single bit. | 18:25.35 |
| Robin_Watts | henrys: I'd love to be wrong, but from looking at the code now, if 'uses_d' is set, we always pass in 'expand_options'. And that always asks for 8 bit chunky. | 18:26.10 |
| henrys | you are probably right about the not - I was thinking of drawing on blank say a bounding box for a complex object drawing the complex path with not. But that is specialized let me look for some sample files. | 18:26.32 |
| Robin_Watts | I think you'd use 'AND' to do clipping. | 18:26.59 |
| | Have the thing you want to plot as a the S, and the clip path as T. | 18:27.14 |
| | and then use a rop of D | (S&T) | 18:27.33 |
| Lafriks|away | Robin_Watts: http://bugs.ghostscript.com/show_bug.cgi?id=692518 and http://bugs.ghostscript.com/show_bug.cgi?id=692519 | 18:28.13 |
| henrys | you can't have a clip path as T | 18:28.15 |
| | no vectors in patterns. | 18:28.27 |
| | only images. | 18:28.36 |
| Robin_Watts | Ok, so you have the image to clip as T, and the clippath as S ? | 18:29.43 |
| henrys | but still yes I think you are right about & | 18:29.43 |
| Robin_Watts | Basically the main strip_copy_rop code forces everything into one common 'lowest common denominator' format, and then operates on that. | 18:31.10 |
| | We could possibly be smarter about picking the 'lowest common denominator' rather than just assuming that '8 bit rgb chunky' will be the one we want. | 18:31.43 |
| | Various devices may have such smartness for their common cases in, but the default one is the one they all fall back to. | 18:32.20 |
| | If we had CMY data (rather than CMYK) then it would be possible to do without the conversion step. | 18:33.57 |
| henrys | the perfomance improvement of getting 1 bit should be quite large right? | 18:34.50 |
| Robin_Watts | Basically we'd do some magic to the rop number (bit reverse it?) and then just pretend the CMY was RGB. | 18:34.51 |
| | henrys: Maybe. | 18:34.58 |
| henrys | I mean now we must be doing each operation for a bit in a byte of data. | 18:35.27 |
| mvrhel2 | I would think we would just do an operation directly on the destination data as it is | 18:35.34 |
| Robin_Watts | henrys: If S and T are either unused or in 1 bit, then we can stay in 1 bit. | 18:35.35 |
| | mvrhel2: Sorry? Can you say the same thing using different words ? | 18:35.58 |
| mvrhel2 | well, I would like to avoid converting CMYK to CMY or RGB and I would like to avoid going from 1 bit to 8 bit | 18:36.10 |
| Robin_Watts | mvrhel2: I'd like to avoid the same. | 18:36.22 |
| | I hadn't twigged that we were always forcing to 8 bit. | 18:36.47 |
| | (until this conversation) | 18:36.53 |
| mvrhel2 | I would like to determine a way to take a rop and apply it on the CMYK binary values to get more or less the desired effect | 18:37.09 |
| Robin_Watts | CMYK - you can't,. | 18:37.18 |
| | CMY, you can. | 18:37.22 |
| mvrhel2 | well yes, you can. you do need to bring K into the fold | 18:37.38 |
| Robin_Watts | CMY = (notR, notG, notB) right? | 18:37.41 |
| mvrhel2 | and you have only two cases | 18:37.43 |
| | K is either 0 or 1 | 18:37.47 |
| Robin_Watts | I had a example of why this is a problem the other day. | 18:38.17 |
| mvrhel2 | I really worry about the fact that we are hafltoned here | 18:38.18 |
| Robin_Watts | Take for example, the 'invert' rop. | 18:38.32 |
| | rop(0x0f), which is f(d,s,t) = not d | 18:39.05 |
| mvrhel2 | ok | 18:39.14 |
| Robin_Watts | White is CMYK = 0000. | 18:39.22 |
| | Convert that to RGB, you get 111, rop that you get 000, convert back you get 0001 | 18:39.43 |
| mvrhel2 | be careful here | 18:39.52 |
| | as the mappings as not one-to-one | 18:40.00 |
| Robin_Watts | Indeed. Hence my carefully picked examples :) | 18:40.25 |
| mvrhel2 | that is why we do it all in cmyk | 18:40.29 |
| | directly | 18:40.30 |
| Robin_Watts | mvrhel2: What I've just described is the 'correct' answer. | 18:40.51 |
| mvrhel2 | I did not say it was not correct | 18:41.32 |
| Robin_Watts | How would you achieve that same result by staying in cmyk ? | 18:41.46 |
| mvrhel2 | well, I have 16 possible values | 18:43.03 |
| Robin_Watts | For CMY, the equivalent rop would still be not d, right? | 18:43.15 |
| mvrhel2 | for my destination values | 18:43.19 |
| Robin_Watts | Yes. | 18:43.22 |
| mvrhel2 | I can have this do the right thing I believe | 18:43.31 |
| Robin_Watts | Wooah. Where do you have 16 values? | 18:43.54 |
| mvrhel2 | I have 4 bits of cmyk values | 18:44.10 |
| | in my destination | 18:44.15 |
| Robin_Watts | The rops still only have d,s,t as input. | 18:44.19 |
| mvrhel2 | yes but the output is only 16 different possiblities | 18:44.48 |
| Robin_Watts | So rops only operate on a single component at a time (and bitwise at that) | 18:44.53 |
| mvrhel2 | i fear though this is going to give some odd results | 18:45.27 |
| Robin_Watts | Sorry, I should let you talk me through what you intend rather than jumping to (probably incorrect) conclusions. | 18:45.52 |
| mvrhel2 | well I am just babbling a bit here, trying to understand why we have to go to RGB or CMY | 18:46.21 |
| | we have CMYK binary data | 18:46.31 |
| | in the destination | 18:46.34 |
| | at a particular spatial location that is 4 bits of data | 18:46.46 |
| | the ROP is going to map those 4 bits to a different set of 4 bits | 18:47.07 |
| | end of operation | 18:47.30 |
| | or am I missing something | 18:48.17 |
| Robin_Watts | The essential thing about rops is that they only operate on one component at a time. | 18:48.24 |
| mvrhel2 | forget about that for a second | 18:48.39 |
| | K complicates that and introduces a channel dependency | 18:48.55 |
| Robin_Watts | They take 3 'planes' of data (3 planes of red, or 3 planes of blue, or 3 planes of green), 'convolve' them together and spit out a new plane. | 18:49.11 |
| mvrhel2 | hence my desire to think in terms of mapping 4 bits to a new set of 4 bits | 18:49.11 |
| Robin_Watts | 12 bits to 4 bits. | 18:49.27 |
| mvrhel2 | If I have a dependency on D (where in your example you had only a dependency on D), it is easy to make a 4 bit to 4 bit mapping to do the rop | 18:50.26 |
| Robin_Watts | Yes, but that's a very simplistic example. | 18:50.33 |
| mvrhel2 | you are the one who made it :) | 18:50.43 |
| Robin_Watts | Imagine D|(S&T) | 18:50.43 |
| | Which is rop 0xF8. | 18:50.57 |
| henrys | bbiab | 18:51.33 |
| Robin_Watts | To cope with the full generality of rops, you'd need your special 'MichaelOp' (or mop for short :) ) to take 12 bits to 4. | 18:52.01 |
| | yes? | 18:52.23 |
| mvrhel2 | Robin_Watts: yes, in this case, the simple mapping does not work, but I have not looked at this to see if we need to color convert yet | 18:53.28 |
| | let me think for a sec | 18:53.38 |
| Robin_Watts | ok. | 18:53.42 |
| mvrhel2 | I feel that the proper approach to this, may be to break K out. and handle it a bit special | 18:54.21 |
| | manner | 18:54.26 |
| | I don't have a quick solution that this time, but that is just my feeling | 18:54.55 |
| | s/that/at/ | 18:55.02 |
| Robin_Watts | I agree. If it wasn't for K, everything would be 'separable'. | 18:55.32 |
| mvrhel2 | that is, if K is 1 then we are going to essentially ignore CMY | 18:55.37 |
| Robin_Watts | We could then operate on CMY exactly as if it was RGB (with some rewriting of the rops) | 18:55.58 |
| mvrhel2 | i.e. if I have a black dot treat it as C=M=Y=K for rops | 18:56.02 |
| | if K = 0, then deal with CMY | 18:56.19 |
| Robin_Watts | If we take the view that K = 1 iff C=M=Y=1 then we're in the position of not needing K at all. | 18:56.46 |
| mvrhel2 | I did not say that | 18:57.00 |
| Robin_Watts | I know, but bear with me. | 18:57.09 |
| mvrhel2 | this is for dealling with rops treatment | 18:57.21 |
| Robin_Watts | Then we can operate in CMY and just generate K from it at the end. | 18:57.28 |
| mvrhel2 | on halftoned data | 18:57.33 |
| | no | 18:57.38 |
| | we need to keep color managment alive | 18:57.50 |
| Robin_Watts | Under my proviso above, yes. | 18:57.54 |
| mvrhel2 | for non-roped regions | 18:57.58 |
| | you dont know when you draw in the destination if there is an upcoming ROP that will be applied there (I assume) | 18:59.51 |
| | So, you do proper conversion to CMYK with the CMM | 19:00.10 |
| Robin_Watts | I believe that's true, but I'd need henrys to be sure. | 19:00.24 |
| | I can't see how we can get both color management and fast rops at the same time. | 19:01.10 |
| mvrhel2 | why? | 19:01.26 |
| | ignore that | 19:02.12 |
| Robin_Watts | Actually, I might go further. | 19:02.26 |
| | I cannot see how you can get both color management and rops at the same time. | 19:02.40 |
| mvrhel2 | I agree that once you start to do rops the question of managed color comes in to play | 19:02.41 |
| Robin_Watts | right, we're at the same place :) | 19:02.50 |
| mvrhel2 | the proper solution is that it is all done in RGB and managed at the end | 19:03.14 |
| | that is what we would *like* to see | 19:03.21 |
| | it being the ROPs done in contone RGB and the CMM done at the end followed by halftoning | 19:03.48 |
| Robin_Watts | If you assume that the rops are only being used on 'saturated' color, and we're halftoning (so basically, flipping things on and off) then I can see that you can have rops with halftoned color managed data. | 19:03.57 |
| mvrhel2 | that is the *proper* approach | 19:04.01 |
| Robin_Watts | Actually, even that's not true :( | 19:04.35 |
| | The conversion to rgb and back can 'corrupt' the halftones. | 19:04.54 |
| | Sidebar, quickly if I may.... | 19:05.25 |
| mvrhel2 | once you hafltone, you have lost the ability to do proper color conversions | 19:05.26 |
| | what you have to be is consistent though | 19:05.38 |
| | in going back and forth | 19:05.43 |
| Robin_Watts | halftone tiles; are they typically different sizes in each plane ? | 19:05.54 |
| mvrhel2 | since RGB to CMYK is not a one-to-one mapping that is not possible | 19:06.07 |
| Robin_Watts | indeed. | 19:06.15 |
| mvrhel2 | unless you do CMYK to RGBK | 19:06.19 |
| | which means you might as well stay in CMYK | 19:06.31 |
| setmeaway | i used svgwrite device in gs with rasterop enabled. but i got generated svg file stripped color information. is this supposed one? | 19:06.53 |
| Robin_Watts | (Another sidenote, if you look at the PCL manual that henrys sent, page 5-15 (79) "ROPS in the CMY space", you'll see it talks about CMY, not RGB. | 19:08.01 |
| mvrhel2 | the halftone sizes can and usually are different sizes. If you want to make a super-duper chunky screen, the screen can be quite large to combine them all with the proper periodicity | 19:08.01 |
| Robin_Watts | CMY, not CMYK. | 19:08.11 |
| mvrhel2 | Robin_Watts: yes | 19:08.15 |
| | but the fact is very few CMY printers exist | 19:08.29 |
| Robin_Watts | Right. So it's perfectly reasonable to get 1111 and 0001, both representing black in the same page. | 19:08.50 |
| mvrhel2 | I only know of dye sublimation printers that are CMY and those use contone data | 19:08.52 |
| | Robin_Watts: and 111- | 19:09.03 |
| | 1110 | 19:09.06 |
| Robin_Watts | indeed. | 19:09.11 |
| mvrhel2 | but note | 19:09.21 |
| Robin_Watts | OK. Was just confirming that we couldn't assume that we'd only have 1 representation of black on the way in to a rop. | 19:09.42 |
| mvrhel2 | 0101, 1001 1101 1011 could all be considered "black" (perhaps) for us with rops | 19:09.55 |
| | basically if K=1 we would call that black | 19:10.29 |
| | and do the quick rop for that | 19:10.31 |
| | if K=0 we use CMY to figure out what to put | 19:10.41 |
| Robin_Watts | mvrhel2: OK, now the way we implement rops in ghostscript... | 19:10.53 |
| | Originally, peter had a set of 256 functions, one per rop. | 19:11.13 |
| mvrhel2 | yes, where are these? | 19:11.23 |
| Robin_Watts | So he'd pick the function pointer out of a table. | 19:11.30 |
| mvrhel2 | I see a ->run operation | 19:11.31 |
| Robin_Watts | Then call function(d,s,t) and get a result back. | 19:11.44 |
| | Each of d,s,t could be any 'register' size. | 19:11.56 |
| | So we can do up to 32 bits at a time. | 19:12.02 |
| mvrhel2 | where do you get 32 bits? | 19:13.12 |
| Robin_Watts | 32bits = typical size of an int. | 19:13.31 |
| mvrhel2 | ok | 19:13.44 |
| Robin_Watts | So if you've got rgb in chunky 8 bit format, he can load an int from d, from s, from t, call the function, store it back. | 19:14.25 |
| | And you've done a pixel. | 19:14.35 |
| | If you're ropping monochrome data, you can do 32 pixels at the same time. | 19:14.59 |
| mvrhel2 | ok that makes sense | 19:15.15 |
| Robin_Watts | But that means a function call per 'int'. | 19:15.56 |
| | I introduced some code, (the roprun stuff) that does runs of rops. | 19:16.19 |
| | It allows us to spot the common cases and to efficiently code just those ones. | 19:16.46 |
| mvrhel2 | oh that is the stuff I was looking at | 19:17.21 |
| Robin_Watts | Now, with what you're suggesting, (having K as special), we completely lose the ability to take either peter or my approach. | 19:17.35 |
| mvrhel2 | yes. I see that | 19:17.57 |
| | let me think a sec | 19:18.08 |
| Robin_Watts | I have to go to dinner, so just let me braindump my last thoughts. | 19:18.27 |
| | No, they've vanished. Sorry. | 19:18.46 |
| mvrhel2 | there is a lot going on here | 19:18.56 |
| Robin_Watts | I'll check back after food. | 19:18.56 |
| mvrhel2 | one worry, that I have is that our theory of even doing this on halftoned data is halftbaked | 19:19.17 |
| Robin_Watts | Oh yes, cross dependencies on components is especially bad for planar devices. That was it. | 19:19.35 |
| mvrhel2 | yes. I can see this | 19:20.08 |
| | if the data is chunky it is not such a problem | 19:20.39 |
| | let me think a bit about this | 19:20.42 |
| | I am going to go eat some lunch now | 19:20.50 |
| Robin_Watts | Yes, operating on halftones isn't ideal. The 'gold standard' would clearly be to stay in color managed contone throughout and to halftone at the end. | 19:22.20 |
| | Just had another idea - haven't fully thought it through though, so... | 20:02.00 |
| | Suppose when we're asked to do a rop on cmyk data, we 'invert' the rop to get the rop to do on the cmy planes. | 20:02.48 |
| | Then we look the rop up again to get the rop to apply to k. | 20:03.00 |
| | Maybe there is no second lookup. | 20:06.17 |
| | Maybe we just 'invert' the rop once. | 20:06.43 |
| | If rops are only used for clipping or inversion, then we'll get exactly the results we want. | 20:07.00 |
| | Color management wouldn't be affected (if we only use clipping) | 20:26.26 |
| Lafriks | Robin_Watts: have you had a chance to look at patches? | 20:27.48 |
| Robin_Watts | No, sorry, I won't get a chance today. | 20:28.00 |
| | Did you see my comment earlier? Can you open a bug and attach the patches to the bug. That way they won't get forgotten. | 20:28.20 |
| Lafriks | yes, I already did | 20:28.35 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=692519 | 20:28.42 |
| | and | 20:28.57 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=692518 | 20:28.58 |
| Robin_Watts | Thanks. | 20:29.49 |
| Lafriks | I hope I made them in right way (have no much experience with git) | 20:31.46 |
| henrys | mvrhel2:chrisl's suggestion was to install an rgb -> cmy profile when pcl was running then we would never have the K plane issue. The question becomes is it possible to do low end business graphics (pcl stuff) with this model. Of that I'm not sure. | 20:39.08 |
| mvrhel2 | henrys: restricting us to rgb->cmy profiles is likely to be pretty constraining I would think to most printer application | 20:48.53 |
| | s | 20:48.55 |
| | at the end of the day, we do need to generate some sort of K channel | 20:49.42 |
| | trying to generate that from cmy hafltoned data with a proper screen angle would be a bit messy probably. I can think of ways to do it, but they involve descreening | 20:50.50 |
| henrys | yes I am assuming a postprocess we certainly want K and not CMY but you are probably right | 20:50.56 |
| mvrhel2 | one thing is that with 4 bit CMYK data, our memory footprint of the destination data is pretty small | 20:51.53 |
| | having a pointer to the K plane and the C, M, or Y plane is not really that bad in doing a run of a raster op | 20:52.22 |
| | I would think | 20:52.25 |
| henrys | yes at 4 bit 600 dpi not too painful. | 20:52.57 |
| mvrhel2 | the cross ependency of the operation on the C, M, Y and K planes is one where really we have C,K M,K Y,K as destination pointers | 20:53.56 |
| | to perform some run on | 20:54.06 |
| | basically we have this check on the K value, which if it is 1, we will assume we have black | 20:54.43 |
| | else we use the C,M or Y value | 20:54.54 |
| | I need to understand better how Robin_Watts performs his run rop operation | 20:56.55 |
| henrys | so if the result of the operation is 111 do we right back 0001 | 20:56.56 |
| | ? | 20:57.11 |
| mvrhel2 | oh. is that the desired result? | 20:57.43 |
| | here is the deal | 20:58.31 |
| henrys | well it isn't invertible if you don't that right? | 20:58.46 |
| mvrhel2 | well lets say I have 1 1 1 1 at my destination to start with | 20:59.09 |
| | which is black | 20:59.16 |
| | vs. 1 1 1 0 at my destination to start with | 20:59.30 |
| | vs 1 0 0 1 | 20:59.39 |
| henrys | already confused 0001 is black | 20:59.40 |
| mvrhel2 | etc | 20:59.40 |
| | well black in cmyk space is a funny thing | 21:00.15 |
| | this is where we get ourselves in trouble with pcl and color management | 21:01.41 |
| | basically you can have many cmyk values that all represent black | 21:02.34 |
| | vs. in rgb space you have one color that represents black | 21:02.48 |
| henrys | yes I do wonder about chrisl's idea then on the back end we always print 111 as pure black (just K) | 21:02.59 |
| Lenhix | Noob questoin: is PS format all human-readable? I mean, can I output it safely to a browser (for testing)? | 21:03.37 |
| mvrhel2 | the problem with this is that once we hafltone we have lost the ability to do K generation without a lot of work | 21:03.58 |
| henrys | well where are we stuck now assuming we are just going to do it the way the library has it now and have a special case for K - I know the chunky stuff works approximately. | 21:05.41 |
| | it seems get_bits needs to be changed to fetch planes and not convert to chunky? | 21:07.19 |
| mvrhel2 | well, Robin mentioned that he has a fast rop run operation that handles multiple chunky pixels at the same time. I would suggest that we create a similar set of operations that grabs pointers to the C, M, Y, K data planes and while operating on C it notes also what the value of K is. like wise for M and Y | 21:08.41 |
| | actually, a check on K would be done first | 21:08.56 |
| | personally, I think this could be done *very* nicely with SSE2 | 21:09.24 |
| | where we operate on 32 pixels at once | 21:09.47 |
| | my fear though is that we are making two approximations here. one is that doing the rop on halftone and the other is doing the rop in CMY(K) is going to give wacky results. I am sure there are ROP cases where it fails | 21:10.48 |
| | part of me would like to sit down and code this up in MATLAB or something to compare each operator in contone RGB with the CMYK hafltone approximation | 21:11.24 |
| henrys | Lenhix:PostScript programs can be written to be human readable but don't have to be. | 21:11.40 |
| mvrhel2 | henrys: I need to run off to get the kids. i will bbiab | 21:12.47 |
| henrys | sse2 might be a bad assumption for embedded printers. | 21:12.48 |
| mvrhel2 | yes | 21:12.53 |
| henrys | okay we'll see what Robin_Watts has to say when he returns. | 21:13.13 |
| Lenhix | henrys: like in the case they include binary data like an image? | 21:15.26 |
| henrys | Lenhix:http://www.adobe.com/products/postscript/pdfs/PLRM.pdf section 3.2 | 21:19.56 |
| Lenhix | ok henrys :) | 21:21.40 |
| | Anyone here does have an opinion on how good/buggy/reliable/etc is paps(1) to convert TXT to PS? | 22:07.36 |
| | What does a exit code of 2 mean? | 22:25.06 |
| Robin_Watts | Back. | 23:11.06 |
| | I think rops with more than one non-saturated input are basically unstable. | 23:11.52 |
| | imagine a rop where d and s are supposed to be 128, but maybe through rounding one comes out as 127. | 23:12.20 |
| | With almost any boolean expression you can think of that's radically wrong. | 23:12.41 |
| | Therefore, I reckon, any sane use of rops is going to involve at most one non-saturated input. | 23:13.31 |
| | If you look at it in that light, then I suspect just doing the approximation of running the rop in cmyk space is going to give pretty much the right answer, and will keep color management alive. | 23:14.18 |
| | I'll look tomorrow to see if I still have the rop usage data I gathered before. | 23:15.10 |
| timeless | is anyone here familiar w/ the gs installer/uninstaller? | 23:22.08 |
| Robin_Watts | timeless: You probably want to speak to chrisl in about 8 hours time. | 23:24.26 |
| | but ask the question. | 23:24.30 |
| timeless | thanks, that puts him more or less totally off my schedule (it's 7:30pm here) :( | 23:25.00 |
| | i tried using the gs (9.01) installer on Windows 8 (preview) | 23:25.21 |
| | and it pointed out some items which seemed interesting | 23:25.32 |
| | 1. the uninstaller didn't delete itself, nor did it delete the folders under c:\program files\gs (it did delete everything else) | 23:25.58 |
| | (i did skim through open bugs in the gs bugzilla and didn't find anything relevant, i might file some bugs later, but i'd rather talk to people to learn protocol before i go on a filing spree) | 23:26.33 |
| Robin_Watts | OK. The installer changed completely in in 9.02 or 9.04. | 23:26.37 |
| timeless | ah | 23:26.44 |
| | did you switch to nsis? | 23:26.53 |
| Robin_Watts | Try again with 9.04 (the latest) and see if it still does it. | 23:27.00 |
| | Yes. | 23:27.02 |
| timeless | yeah, i'm cleaning up now and will try another run | 23:27.43 |
| sebras | Robin_Watts: having looked at your pdf_xref with try/catch I | 23:39.53 |
| Robin_Watts | am lost for words? :) | 23:40.20 |
| sebras | m a bit more positive. let's give it a try... ;) | 23:40.22 |
| | no, just apostroph... eh, enter key... | 23:41.49 |
| Robin_Watts | mvrhel2, henrys: See my comments on ROPs above. | 23:44.21 |
| | I'd be interested to know if either of you (especially henrys, with his far greater experience of PCL than me) would disagree with my characterisation of ROPs as primarily being used with at most one non-saturated input. | 23:54.36 |
| | Forward 1 day (to 2011/09/20)>>> | |
IRC Logs
