| | <<<Back 1 day (to 2011/09/20) | 2011/09/21 |
| Zeranoe | Hey I'm wondering if I can use ghostscript to print a page on firefox to a ps or pdf? Sorry if this is a FAQ, I'm new to ghostscript | 00:23.24 |
| kens | aha! | 07:51.58 |
| | You might want to try Chatzilla now chrisl | 07:52.18 |
| chrisl | Yep, that's better................ | 07:54.39 |
| kens | :-) | 07:54.45 |
| Fandekasp | guys | 07:55.18 |
| Fandekasp | is a zombie | 07:55.27 |
| | Does someone know about devilspie here ? | 07:55.39 |
| kens | Not me, never heard of it | 07:55.48 |
| | Souinds like some kind of ancient Mummerset place name | 07:56.13 |
| Fandekasp | I made an *awesome* command to get the title of my current section (latex doc edited with vim): echo substitute(getline(search('\\\(sub\)\?section', 'bn')), '\\\%(sub\)\?section{\([^}]\+\)}', '\1', '') . And I want to have mupdf autosearch this string so that I get directly to the page I'm editing | 07:56.47 |
| | I use devilspie to open mupdf in fullscreen already | 07:57.41 |
| | but I have no idea how to do achieve this new behavior | 07:58.04 |
| | hmm who is mupdf dev here? I think sebras, but I don't know any other | 07:59.06 |
| | dos7 (or something) from the #python channel right ? | 07:59.53 |
| kens | Tor8 is the MuPDF owner, Robin_Watts_ also. But this is not reallly a MuPDF problem it seems to me | 08:00.33 |
| Fandekasp | Yes you're right. I though they might have encounter similar problems and would be able to give me some suggestions *a bit despaired* | 08:02.33 |
| Fandekasp | should have though this a bit more before loosing hours on this vim command | 08:02.52 |
| | hmm maybe I can mix devilspie with xbindkeys | 08:14.06 |
| | hi tor8 | 10:14.27 |
| tor8 | hey | 10:15.16 |
| ghostbot | moin moin | 10:15.16 |
| Fandekasp | Would it be easy to add a -f "searched_string" to mupdf so that I can script it to go directly to the page containing the string? | 10:15.33 |
| | I've fought for hour trying to find an alternative without success ^^ Actually when we press / from mupdf, the paste is not possible | 10:16.44 |
| tor8 | yeah, the text input widget for mupdf is extremely primitive | 10:17.40 |
| | have you tried autokey? | 10:18.22 |
| Fandekasp | I'm fine with that, I'm more interested by a command-line option | 10:18.25 |
| | I tried to install autokey without success tor8 (actually I lost my afternoon search for solutions like that lol) | 10:18.48 |
| | I'm using sabayon, not debian | 10:18.59 |
| tor8 | alright, well, the mupdf source for the viewer is a bit messy but it shouldn't be all that difficult to hack in a new command line flag to do what you want | 10:19.21 |
| Fandekasp | and the autokey setup.py really sucks, doesn't install the dependancies nor allow to uninstall (I had to manually remove each file installed) | 10:19.35 |
| | hmm ok ^^ | 10:19.55 |
| tor8 | I think all you need to add is a call to pdfapp_searchforward() just after initializing and loading the pdf file in x11_main.c. | 10:23.27 |
| | Fandekasp: http://pastie.org/2567662 | 10:30.13 |
| Fandekasp | erf I just realize that there are 2 options -b and -A that I didn't know | 10:30.18 |
| | not writing in the man page, and I never did a mupdf --help lol | 10:30.38 |
| | thank you tor8 :) I have to admit that I'm not confident with c, only did python for years ^^ | 10:31.33 |
| | tor8: how did you do your git diff ? I took the opportunity to learn how to patch a git diff, but patch -p0 fails (means you didn't do a -no-prefix), and patch -p1 get 3 out of 4 hunks failed | 10:36.33 |
| tor8 | oh, because I'm on a different branch probably | 10:37.16 |
| Robin_Watts_ | Fandekasp: git format-patch HEAD~1 will give you the last commit as a patch. | 10:37.18 |
| | Then "git am <whatever the produced file was>" will apply it. | 10:37.34 |
| Fandekasp | 0001-Don-t-invoke-tiling-device-calls-when-there-is-only-.patch | 10:38.04 |
| tor8 | I just grabbed my nearest mupdf repo for that quick patch :) | 10:38.06 |
| Fandekasp | hmm ^^ I'll do the changes manually lol | 10:40.02 |
| tor8 | http://pastie.org/2567688 | 10:40.34 |
| Fandekasp | doesn't work better, doesn't matter :) | 10:41.54 |
| | when I try to make install, I get: | 10:45.41 |
| | apps/x11_main.c: In function âmainâ: | 10:45.41 |
| | apps/x11_main.c:605:11: error: âpdfapp_tâ has no member named âsearchdirâ | 10:45.41 |
| | make: *** [build/debug/x11_main.o] Error 1 | 10:45.44 |
| | gapp = pdfapp_t | 10:46.45 |
| tor8 | Fandekasp: try pulling the latest source from git and applying to that | 10:49.15 |
| | sebras submitted a couple patches fixing a lot of things in the viewer that I've just pushed | 10:49.34 |
| Fandekasp | I did a "git clone git://git.ghostscript.com/mupdf.git" When you suggested me to hack into mupdf (before I just installed it from portage) | 10:51.01 |
| | should already be the latest source isn't it ? | 10:51.16 |
| | wow ok I wasn't :) | 10:52.16 |
| | yeahh | 10:52.42 |
| | that's awesome :) | 10:53.47 |
| Fandekasp | update his vim script | 10:53.53 |
| | ok it works, thanks tor8 :) | 11:35.58 |
| | a note on the search : search for "Something with ' inside" doesn't work | 11:36.22 |
| | living, will be back in 10 min | 11:36.32 |
| | re | 11:49.08 |
| tor8 | Fandekasp: are you sure it's an ' and not a smart quote? | 12:11.55 |
| Fandekasp | is it working for you tor8 ? | 12:13.48 |
| | yes I'm sure it's a ' | 12:15.06 |
| | and not a ` | 12:15.10 |
| tor8 | it works for me on at least the one file I tried with | 12:28.19 |
| Fandekasp | hmm strange | 12:29.15 |
| tor8 | you 100% sure it's a ' and not a â | 12:34.10 |
| Fandekasp | no | 12:38.37 |
| | actually I can't find the keymap for this slightly different quote | 12:38.58 |
| | but if it works for you then yes that might be my problem | 12:40.21 |
| tor8 | nicely typeset text usually uses the proper quote characters rather than apostrophes, sadly typing a quote character is rather difficult | 12:45.35 |
| Fandekasp | hmm ok | 12:48.30 |
| | if there are some vim users interested by the vim script for calling mupdf (here with vim-latex, can be adapted), it's here: http://paste.pocoo.org/show/479828/ | 12:49.15 |
| kens | Hmm, two henrys | 13:47.28 |
| sebras | tor8: I guess I will need to tell people that I'm just a mupdf-dev hangaround... ;) | 13:59.50 |
| Robin_Watts_ | Damn. My code is working fine, it's the rasterops that aren't doing what I'd hoped in cmyk. | 14:20.10 |
| | Suppose we have a black background (000000ff in 8 bpc cmyk) | 14:29.11 |
| | We want to use rop(66) = d^s on that, with a constant s of 00000030 (that's cfcfcf in 8 bpc rgb). | 14:29.56 |
| | To do it via RGB, we convert 000000ff to rgb to get 000000, do the rop, and get cfcfcf, and convert back to get 00000030 | 14:30.54 |
| | Attempting to do it in cmyk, I transform the rop, so instead of using rop(66), we use rop(99) = NOT(d^s) | 14:31.42 |
| kens | Sorry, waaaay beyond me..... | 14:32.46 |
| Robin_Watts_ | Then NOT(000000ff ^ 00000030) = ffffffcf | 14:32.59 |
| | sorry, ffffff30 | 14:33.23 |
| | So we still get black. | 14:33.39 |
| | kens: I'm hoping henrys may have insight. | 14:33.50 |
| kens | Glad you aren't expectin gme to | 14:34.52 |
| dorisabayon | ahaha sorry sebras :) | 14:43.50 |
| henrys` | Robin_Watts:what your tripping over (I think) is noted in the manual - see page 5-18 basically if you do "or" in rgb space you need "and" in cmy instead of not or, right? | 14:58.15 |
| Robin_Watts_ | henrys`: I believe I am allowing for that. | 14:58.32 |
| | In order to 'invert' the sense of rops, you need to reverse the bits in the rop number, and then negate them. | 14:59.11 |
| | I figured that out for myself, and I've since seen it both in the PCL manual you sent, and in the gs code itself, so I'm fairly confident :) | 14:59.42 |
| | That's what changes rop(0x66) into rop(0x99) in my example above. | 15:00.06 |
| henrys` | yes but NOT(d^s) is wrong | 15:00.12 |
| Robin_Watts_ | NOT(d EOR s), that is. | 15:00.31 |
| henrys` | or I'm sorry I was reading that as or | 15:00.51 |
| | you mean xor | 15:01.30 |
| | ? | 15:01.30 |
| Robin_Watts_ | yes. | 15:01.34 |
| henrys` | processing ... | 15:01.46 |
| | right I it should work okay | 15:02.29 |
| Robin_Watts_ | So, you can see a flaw in my working of that example? | 15:03.22 |
| henrys` | I see a flaw in the conclusion but not the steps | 15:04.07 |
| | as you do. | 15:04.27 |
| Robin_Watts_ | Ah, right. | 15:04.34 |
| chrisl | What happens if you don't use the K channel? | 15:04.46 |
| Robin_Watts_ | chrisl: In what way? | 15:05.46 |
| chrisl | Robin_Watts_: for example, background 0000ff00 and constant of 00003000 | 15:06.48 |
| Robin_Watts_ | I haven't worked that example :) | 15:07.20 |
| | This is one I found in an actual pcl file. | 15:07.30 |
| chrisl | Just thinking that the manual states that the printer operates in "something similar to a CMY space" (huh?), so maybe look at CMY colours first before including the K channel | 15:08.36 |
| Lafriks | Hi Robin_Watts_ | 15:08.46 |
| Robin_Watts_ | chrisl: If we work in CMY, I believe we have no problem. | 15:09.14 |
| Lafriks | I have added patch to bug report that also move aa variables to context | 15:09.16 |
| Robin_Watts_ | Lafriks: Thanks. tor8 is now working forwards from my failing_allocs branch, I believe. | 15:10.08 |
| | So he may well look at your patches. | 15:10.15 |
| chrisl | Robin_Watts_: fair enough - as I said, just thinking out loud........ it's a *long* time since I looked at rops. | 15:10.16 |
| Robin_Watts_ | chrisl: I can make this particular example give the right answer if I 'push' the K channel through the C,M and Y channels before doing the rop. | 15:11.19 |
| Lafriks | Robin_Watts_: have you had chance to look at my patches? | 15:11.42 |
| Robin_Watts_ | (i.e. add K to each of C,M,Y) | 15:11.44 |
| | Lafriks: Me, no, I'm up to my neck in other stuff. | 15:11.56 |
| | sorry. | 15:12.10 |
| Lafriks | oh ok | 15:12.13 |
| chrisl | Robin_Watts_: not really the direction you want to go, though. Do we "fast track" trivial case rops? | 15:12.38 |
| Robin_Watts_ | chrisl: Yes. | 15:12.47 |
| Lafriks | no problems | 15:12.48 |
| Robin_Watts_ | Pulling K through C,M,Y is a pain, but it's still better than doing the planar to chunky and rgb conversion. | 15:13.51 |
| chrisl | Robin_Watts_: so these problems don't arise with, for example, rops used to emulate a complex clip? | 15:14.04 |
| Robin_Watts_ | It's possible that it won't work in other examples though. | 15:14.04 |
| | chrisl: I wouldn't swear to that. | 15:14.27 |
| chrisl | I suspect there isn't a "right answer" for this....... | 15:15.31 |
| henrys` | I guess things are arranged "just so" to work only for 3 outputs but it isn't obvious exactly why. | 15:21.15 |
| Robin_Watts_ | henrys: The components in RGB are all independent orthogonal things. | 15:21.39 |
| | Likewise CMY. | 15:21.45 |
| | K however isn't orthogonal to CMY. | 15:21.54 |
| henrys` | ah yes that's it. | 15:22.31 |
| Robin_Watts_ | Converting from CMYK to CMY, then doing the rop, then converting back is possible, and would work. | 15:22.50 |
| | but that's almost as much work as having converted to rgb anyway. | 15:23.02 |
| henrys` | the issue is remembering what was 0001 and what was 111 | 15:23.20 |
| Robin_Watts_ | and it suffers from the same 'mapping all blacks to the same black' thing. | 15:23.36 |
| | indeed. | 15:23.41 |
| henrys` | I asked mvrhel2 abou that yesterday and he said in photos you want 111 but I remain skeptical we can't get away with 0001 all the time for rops. | 15:24.15 |
| Robin_Watts_ | Well, with the current code (going via rgb) we are in exactly that position. | 15:24.57 |
| | henrys: Can you easily construct pcl files? | 15:30.28 |
| henrys | sure what do you need? | 15:30.59 |
| Robin_Watts_ | Put a (color managed) photo in a file twice, and the 'invert' rop one of them twice. | 15:31.00 |
| | That would give us a concrete example of how a photo looks with all it's blacks mapped together. | 15:31.32 |
| henrys | do you have a specifice photo you want to use? | 15:32.20 |
| Robin_Watts_ | henrys: No. | 15:32.33 |
| | You have a colour PCL printer, right ? | 15:32.42 |
| henrys | yes I do, I'll find a photo | 15:32.55 |
| Robin_Watts_ | If we believe the 1bit per component case is the key one, I could construct some code to do planar rops in cmyk by converting from cmyk to cmy, then ropping, then converting back. | 15:39.12 |
| | and that would be quicker than the full rgb round trip, and should give the same results. | 15:39.32 |
| | Morning mvrhel2. We're ropping again. | 15:42.27 |
| henrys | nothing like a little boolean algebra warm up to start the day. | 15:43.02 |
| Robin_Watts_ | I've found an example where working in cmyk doesn't work. | 15:43.16 |
| mvrhel2 | ok | 15:43.34 |
| ray_laptop | still thinks we need to work in CMYt and synthesize the 'K' using the CMYt at the final output (i.e. only map to K if t is set) | 15:44.42 |
| mvrhel2 | ray_laptop: problem is we are already halftoned | 15:45.33 |
| | that would be fine if we were in contone | 15:45.38 |
| ray_laptop | images that print K tend to show a 'flat spot' in black areas compared to surrounding 'near black' that has CMY | 15:45.54 |
| mvrhel2 | ray_laptop: yes, we do want to avoid the issue of K only appearing in images | 15:46.33 |
| | hopefully Robin_Watts work on doing the rops in CMYK keeps that from happening | 15:47.05 |
| Robin_Watts_ | mvrhel2: No. I can't see any way to do rops in CMYK. | 15:47.23 |
| | I've tried my ideas out and have hit a brick wall (i.e. I found a case that does not work). | 15:47.41 |
| mvrhel2 | really? | 15:47.43 |
| | a brick wall | 15:47.52 |
| ray_laptop | Robin_Watts_: does it also fail in CMY ? | 15:48.20 |
| mvrhel2 | ok. how about if you write up the issue to me in an email so I can understand and see if I have any thoughts or ideas | 15:48.22 |
| Robin_Watts_ | The best way I can see to work is to go to CMY, rop there and go back to CMYK. That will give exactly the same results as transiting by RGB. | 15:48.25 |
| | With the same drawbacks too (all the blacks get mapped to 'one true black') | 15:48.48 |
| | mvrhel2: My example is above in the irc logs, but sure, give me a mo, and I'll stick it in an email. | 15:49.09 |
| henrys | mvrhel2:it is in the logs but it isn't clear to me why Robin_Watts can't have a state variable that tells him he read K or CMY. | 15:49.20 |
| ray_laptop | Robin_Watts_: but when you 'go back to CMYK' you have to know whether or not to do the black generation + undercolor removal (in PS terms) because you DON'T want that if it is an image | 15:49.39 |
| Robin_Watts_ | henrys: A state variable for every pixel ? | 15:49.41 |
| | ray_laptop: Indeed. That's the drawback. | 15:49.56 |
| henrys | yes a bit for each pixel in the scanline. | 15:50.09 |
| ray_laptop | Robin_Watts_: yeah, we could call it a tag bit ;-) | 15:50.17 |
| Robin_Watts_ | It's the same drawback the current rgb transiting thing has. | 15:50.25 |
| | henrys: What would that bit represent ? | 15:50.36 |
| | exactly. | 15:50.41 |
| henrys | weather you read 111 or 0001 | 15:50.52 |
| Robin_Watts_ | how about if I read 0101 ? | 15:51.02 |
| ray_laptop | Robin_Watts_: just disallow that | 15:51.44 |
| henrys | you're not allowed to read that ;-) | 15:51.56 |
| Robin_Watts_ | ray_laptop: Can't. We get that all the time because we're reading halftoned stuff. | 15:52.08 |
| | henrys: see answer previously given :) | 15:52.20 |
| | And even if I had such a bit, there would be problems. | 15:52.50 |
| ray_laptop | the color profile would have to have some M along with some K. Disallow that in the color profile | 15:52.52 |
| Robin_Watts_ | ray_laptop: I'll leave that one for mvrhel2 to barf at :) | 15:53.32 |
| | And even supposing I had such a bit. | 15:53.57 |
| | Suppose I have a source which is a bunch of different blacks, and I do an invert rop on it to get whites. | 15:54.28 |
| | sorry, to get white. | 15:55.03 |
| | Then I do an invert on that again - I get back to one true black. | 15:55.16 |
| henrys | Robin_Watts:0101 is converted to cmy as it is now and the K bit is not set. | 15:55.16 |
| ray_laptop | I have seen 'high end' color printing that will add some other colorant to K to get a 'better black', but somebody doing a 4-bit CMYK raster buffer kloodge will have to sacrifice 'good' black (just rely totally on the K toner | 15:55.17 |
| henrys | s/K bit/K bit state variable/ | 15:55.48 |
| Robin_Watts_ | cmyk=0101 converts to cmy=111 and k=0 ? | 15:56.02 |
| henrys | basically we just have a special case for reading 0001 | 15:56.15 |
| Robin_Watts_ | ok, but how long do you expect that state variable to be around for? | 15:56.38 |
| | As I say, what happens if I map an 'invert' rop across a line of mixed blacks. Some 0001 and some 1110. | 15:57.05 |
| | I'd expect to get a line of white pixels, right? | 15:57.13 |
| mvrhel2 | sorry step out for a sec | 15:57.13 |
| Robin_Watts_ | Then if I map invert back across that line, I've gone to 'one true black'. | 15:57.30 |
| | Rays cmyt would work, better in this instance. | 15:58.28 |
| henrys | well we know it can work with tags or a contone buffer but the customer says they use an approximation, that's why I dragged us down this road. | 15:59.26 |
| mvrhel2 | Robin_Watts_; what bothers me, about all of this, is that I have all the information that I need. I have an original CMYK color and I have an operation that I want to perform. I know what affect the operation should have. It should be possible to handle it appropriately | 16:00.09 |
| Robin_Watts_ | henrys: Do we know that? | 16:00.22 |
| henrys | Robin_Watts:I thought the conversation was clear. | 16:01.01 |
| mvrhel2 | I guess, I need to see the case that fails | 16:01.25 |
| Robin_Watts_ | A contone cmyk buffer still suffers from multiple cmyk points being mapped together. | 16:01.28 |
| mvrhel2 | if we do contone, we are doing rgb | 16:02.18 |
| | with tag information | 16:02.40 |
| henrys | for a prototype lets just do it as it in the chunky cmyk device and I'll look at output. | 16:02.49 |
| kens | Time for me to gonight all. | 16:03.36 |
| henrys | I wish I were going ... | 16:03.58 |
| mvrhel2 | henrys: are there some test files that go through all the rops with many different source and destination values? | 16:04.10 |
| kens | I'm gald to, had enough of MM fonts for a lifetime | 16:04.14 |
| | Bye.... | 16:04.21 |
| mvrhel2 | bye kens | 16:04.26 |
| | oh too slow | 16:04.31 |
| Robin_Watts_ | mvrhel2: "I have an original CMYK color and I have an operation that I want to perform." Not quite. You have 3 original CMYK values, and an operation that talks about what should happen to 3 RGB values, to yield another RGB value. | 16:04.55 |
| mvrhel2 | yes. but I don't really lose the original CMYK value | 16:05.24 |
| henrys | yes I wrote a sort of exhaustive test tests_private/customer_tests/all_rops.pxl | 16:05.25 |
| mvrhel2 | at the end | 16:05.27 |
| | and I can use some knowledge about what I might expect to occur | 16:05.57 |
| | I know I am being fuzzy | 16:06.13 |
| Robin_Watts_ | mvrhel2: There is only one "white point" in cmyk. | 16:06.20 |
| mvrhel2 | but, I need to see the failing case | 16:06.24 |
| Robin_Watts_ | There are multiple black points in cmyk. | 16:06.32 |
| mvrhel2 | Robin_Wattts_: yes I know this | 16:06.39 |
| | trying to read the logs now.... | 16:06.59 |
| Robin_Watts_ | Therefore if we map black to white in one rop, then white to black in another, we have no way of recovering what blacks were used. | 16:07.55 |
| henrys | ray_laptop:I have been looking at the rotated interpolation banding bug periodically so help out with your bugs, so leave that one for now. | 16:09.05 |
| mvrhel2 | ah but you know the original black | 16:09.11 |
| | you have the CMYK color | 16:09.33 |
| henrys | I guess I can assign it to me, I assumed you weren't going to get to it soon. | 16:09.39 |
| Robin_Watts_ | mvrhel2: Not between 2 rops I don't. | 16:10.45 |
| mvrhel2 | ah ok | 16:11.00 |
| | yes, in that case, you have lost how black was defined | 16:11.12 |
| Robin_Watts_ | Now, cmyt may get me past that. | 16:11.26 |
| mvrhel2 | this is where having a tag bit would help | 16:11.31 |
| chrisl | Wouldn't a tag to indicate sampled image data be better than a tag for text? | 16:12.19 |
| Robin_Watts_ | Is cmyt enough? Or do we need cmykt ? | 16:12.28 |
| mvrhel2 | yes. image or not_image | 16:12.43 |
| | no you need K | 16:12.49 |
| | K is generated from contone data | 16:12.58 |
| Robin_Watts_ | Well, it'd be nicer to have 't = k or not k', maybe? | 16:13.07 |
| mvrhel2 | t = 1 image t= 0 not image | 16:13.22 |
| | k can be anything | 16:13.28 |
| | in contone world | 16:13.37 |
| Robin_Watts_ | You're assuming that the only place I'd ever want to see compound black rather than true black would be in an image. | 16:14.30 |
| | How about if I want to have line art that looks the same as the image? | 16:14.46 |
| mvrhel2 | yes. It is probably a valid assumption. better than saying there is no K around... | 16:15.02 |
| Robin_Watts_ | Would be nicer to have 't' meaning 'use true black here'. | 16:15.04 |
| mvrhel2 | whats true black? | 16:15.18 |
| Robin_Watts_ | k. | 16:15.23 |
| | but yes, I see that is problematic for contone. | 16:15.48 |
| mvrhel2 | part of me really wonders if we are that slow if we did planar contone RGB --> SSE2 conversion to CMYK --> SSE2 halftone but I guess that is basically what was wrong with wtsimdi | 16:17.51 |
| | anyhow, I think for now, we just push forward and have you go ahead and use pure K | 16:19.04 |
| | with rops | 16:19.08 |
| | that is black always goes to 0001 | 16:19.21 |
| | and be done with it | 16:19.24 |
| henrys | one vot yea here. | 16:19.30 |
| chrisl | Robin_Watts_: you are remembering that this is, at best, an approximation - we're in "good enough, most of the time" territory.... | 16:19.38 |
| mvrhel2 | we are already cutting corners already by working with hafltone data | 16:19.41 |
| | and we just need to move on | 16:19.55 |
| | the goal here is speed right now | 16:20.08 |
| | if some rops come out with less than optimal blacks, we will worry about that when that bug is opened :) | 16:20.42 |
| Robin_Watts_ | mvrhel2: Yes, I think that I should do code that goes as fast as possible and gives us the same results that RGB does. | 16:20.51 |
| | Though, I too wonder how bad it would be to work in contone RGB all the way and then color correct convert to CMYK and then halftone. | 16:22.23 |
| mvrhel2 | I do think it may be interesting to look at making a planar RGB device that replaces wtsimdi with a fast color conversion and the fast thresholding stuff | 16:22.24 |
| | yes my thoughts too | 16:22.36 |
| Robin_Watts_ | But why would that be a planar device? | 16:22.40 |
| mvrhel2 | that should be easy to implement | 16:22.43 |
| | fast thresholding | 16:22.47 |
| | actually chunky in would be fine. | 16:22.59 |
| | color convertor would make it planar | 16:23.05 |
| Robin_Watts_ | We'd work in chunky RGB, then convert to CMYK and split to planes at that point. | 16:23.07 |
| mvrhel2 | yes | 16:23.11 |
| Robin_Watts_ | yes. Must type faster :) | 16:23.14 |
| mvrhel2 | we are in sync | 16:23.15 |
| | that has the potential to be fairly quick due to your fast run rop operation with the chunky | 16:23.49 |
| | I could work on a quicker cmm for color conversion in the device | 16:24.09 |
| | that operates on chunks of data | 16:24.31 |
| | just what we need. another project before we have this one finished | 16:24.53 |
| henrys | looking at the customer's printer specifications (current product in the field) I see 2 bit per component output also... joy | 16:25.19 |
| mvrhel2 | so are we all in agreement that we will with rops, just handle black as 0 0 0 1 | 16:25.21 |
| | when working in CMYK | 16:25.41 |
| henrys | I agree | 16:25.43 |
| mvrhel2 | with the knowledge that we may need to revisit this. we really need to see if we are fast enough and getting ok results in general before sinking too much time in this black issue | 16:27.00 |
| Robin_Watts_ | mvrhel2: So, my current plan is to write special code for the 1bpc planar cmyk case that will convert to cmy, do the rop there, and convert back to cmyk. | 16:28.44 |
| | That will still involve walking all 4 planes at once (as planar_to_chunky does), but we'll be writing the results back out immediately rather than letting it all fall out of cache and then writing it out. | 16:30.11 |
| | Also, I'll operate on the bits directly rather than calling map_color_rgb and map_rgb_color functions for every pixel. | 16:31.08 |
| mvrhel2 | Robin_Watts_ : ok. I do wonder if there are any special optimizations that you can do if K = 1 vs K = 0 | 16:31.53 |
| Robin_Watts_ | I'll be doing 32 pixels at at time. | 16:32.23 |
| mvrhel2 | nice | 16:32.30 |
| Robin_Watts_ | (loading an int worth of C, M, Y, K, and then doing boolean ops). | 16:32.51 |
| mvrhel2 | ok | 16:33.01 |
| Robin_Watts_ | So spotting K=1 or K=0 becomes impossible. | 16:33.10 |
| mvrhel2 | yes. i understand | 16:33.17 |
| | that would slow things down | 16:33.25 |
| Robin_Watts_ | My code will only cope with the constant S, constant T, case, at least initially. | 16:33.52 |
| | That's the case that this file uses exclusively. | 16:34.09 |
| | We can expand it later if required. | 16:34.22 |
| mvrhel2 | sounds good | 16:35.49 |
| henrys | okay I have an interesting rop test now - it should erases the page in contone rgb, and leave "sprinkles" with the x11cmyk device time to see what the hp does with it. | 16:41.14 |
| | this is the color managed photo | 16:41.25 |
| | I know we've decided but I was curious. | 16:41.47 |
| | s/it should/it does | 16:42.31 |
| | hp does the example correctly I guess I already knew that but was hoping it wouldn't. | 16:46.01 |
| | the approximation is surprisingly good though I was expecting worse. | 16:47.55 |
| Robin_Watts_ | henrys: So, what exactly does the file do? Draw a picture, then EOR the picture on top ? | 16:52.01 |
| henrys | yes | 16:52.24 |
| Robin_Watts_ | We'd expect that to be exact, surely? | 16:52.35 |
| | Both source and dest get converted to rgb (which squashes blacks) eors to give white, then converts back to white in cmyk. | 16:53.12 |
| | The test I suggested earlier (2 copies of the same picture side by side, then invert one of them with rops twice) should show differences. | 16:53.49 |
| | In one the image (may) have many different blacks. In the other they'll all be squashed together. | 16:54.14 |
| henrys | I don't expect my test to be exact and it isn't empirically. | 16:56.20 |
| Robin_Watts_ | But why isn't it? | 16:56.33 |
| henrys | becuase I assume there is error in reading the code back 0001 is read back as 111 and it was never 111 in the first place. | 16:59.08 |
| Robin_Watts_ | henrys: The code that 'reads it back' will be the getbits in the middle of the rop code, right? | 16:59.36 |
| | Well, that reads it back as rgb, so the question of which black it was shouldn't occur. | 16:59.59 |
| henrys | I guess I am confused I we have an icc profile that goes rgb -> cmyk are you saying these are one to one? | 17:08.13 |
| Robin_Watts_ | rops don't use no stinkin' profile! | 17:08.57 |
| henrys | the code is color managed in the image code before the rops see it. | 17:09.24 |
| mvrhel2 | :) | 17:09.26 |
| Robin_Watts_ | henrys: Ok, I fear I'm dragging us further off track, but.... | 17:09.44 |
| | The image code converts the image and then calls to draw it onto the memory device. | 17:10.16 |
| | So we end up with a CMYK representation of the image on the output device. | 17:10.31 |
| | Then we call the same image code to rop that image onto the same memory device. | 17:10.51 |
| | So the same color conversion goes on. | 17:11.01 |
| | and the rop code gets called with the same cmyk source data as was previously put onto the memory device. | 17:11.27 |
| | The rop code then converts that source cmyk data to rgb. | 17:11.44 |
| | It reads the cmyk data back from the device, also converting it to rgb. | 17:11.58 |
| | You'd like to believe it'd get exactly the same thing, right? | 17:12.09 |
| | Then it combines them with EOR, and you'd hope that should give you exactly white. | 17:12.27 |
| henrys | not with halftoning no certainly not. | 17:12.34 |
| mvrhel2 | right | 17:12.45 |
| Robin_Watts_ | Ah, halftoning. | 17:12.50 |
| | Sorry, hadn't twigged that this device had halftoning. | 17:13.02 |
| Robin_Watts_ | returns to the rop dungeon in shame. | 17:13.13 |
| henrys | what is interesting about my experiment is how well we do - there is just a sprinkling of dots after erasing and that is hopeful the approximation will work. | 17:14.05 |
| Robin_Watts_ | henrys: Your experiment doesn't take note of the black compression though. | 17:14.45 |
| henrys | right you are I'll do that next. | 17:15.01 |
| | I am fairly certain HP does everything in contone but they also have an asic for doing color conversion and halftoning, we don't and I guess our customer doesn't either. | 17:20.18 |
| Fandekasp | hmm tor8 I'm having another bug, maybe it's my sabayon again which causes that. When I put hyperref in the doc, internal references work fine, but hyperlink (websites) doesn't open my default browser, and I'm unable to use any of the mupdf keymap, keeping the loading mouse icon | 17:24.40 |
| henrys | is tempted to go out and buy the customers printer. | 17:32.41 |
| mvrhel2 | that might be worthwhile to do | 17:36.29 |
| henrys | the double inversion does not result in visual differences on the hp and oddly our code looks reasonable too - but it isn't exact, suggesting either I've chosen a bad test file or we don't have a problem. | 17:42.08 |
| | I suggest we just continue on ... | 17:43.39 |
| Robin_Watts_ | henrys: Does the vanilla image appear with K for black when printed? | 17:43.40 |
| | or CMY ? | 17:43.46 |
| henrys | searching for my magnifying glass. | 17:45.51 |
| Robin_Watts_ | If we're printing the vanilla image with black anyway, (or rather, if the vanilla image never has CMY for black) then the ropping won't cause a problem. | 17:46.57 |
| henrys | all the blacks in the photo do appear to have cmy contributions. | 17:50.24 |
| | suggesting we may need tagging but I still like sticking with going forward with our current course. | 17:54.37 |
| | lunch bbiab | 18:09.49 |
| mvrhel2 | bbiaw | 18:27.19 |
| Robin_Watts_ | I have the constant s/t 4bit cmyk planar case coded. Seems to be working, but in this mode I'm getting a lot of bitmap s too :( | 19:33.47 |
| | Will need to code that case too. | 19:33.53 |
| henrys | I'll be heading out a bit early today and coming back to work tonight, I'll check the logs. | 19:49.52 |
| | Forward 1 day (to 2011/09/22)>>> | |
IRC Logs