| | <<<Back 1 day (to 2013/11/03) | 2013/11/04 |
| Robin_Watts | ray_laptop: ? | 00:38.27 |
| | The current patches on robin/master give no noticable differences under bmpcmp. about 8 reported or so. | 00:38.59 |
| henrys | Robin_Watts: wow 3 third world countries in one trip! | 14:03.48 |
| Robin_Watts | Only if Texas secedes :) | 14:06.43 |
| | There was a possibility of flying via spain, so that could have been 4. | 14:07.25 |
| henrys | last company trip there Miles equipped us all with bubba teeth http://www.faketeeth.net/servlet/Search?category=Billy+Bob+Teeth | 14:12.25 |
| Robin_Watts | hehe | 14:13.58 |
| | Morning marcosw, ray_laptop | 15:56.20 |
| | and mvrhel_laptop | 15:56.24 |
| | marcosw: I just got a mail telling me that the Gamestick is being delivered on wednesday. | 15:56.51 |
| marcosw2 | Robin_Watts: that's exciting, how late is it? | 16:20.47 |
| Robin_Watts | marcosw2: Only about 6 months :) | 16:21.12 |
| | I've pledged for castAR glasses too, so next year you might get them too. | 16:21.44 |
| | You're never planning to move house, right? :) | 16:21.53 |
| mvrhel_laptop | morning Robin_Watts | 16:30.07 |
| marcosw | Robin_Watts: we're probably not moving until the kids go to college in 5 years (at which point we'll move and not give the kids the new address) :-) | 16:33.00 |
| mvrhel_laptop | :) | 16:33.10 |
| Robin_Watts | :) | 16:41.15 |
| ray_laptop | morning, all | 16:42.56 |
| | I was on the phone. | 16:43.01 |
| | I have a pre-op and have to leave in about 1.5 hrs -- no idea how long I'll be there. then tomorrow I have the op on my finger at about the same time. I may be typing funny tomorrow pm, (moddle finger left hand) | 16:44.55 |
| Robin_Watts | ray_laptop: Crumbs. This is the first I've heard of this. | 16:45.45 |
| | Is something wrong with your middle finger? Excess wear and tear from driving in LA? :) | 16:46.19 |
| chrisl | pressing too hard on the saxophone valves? | 16:46.56 |
| Robin_Watts | ray_laptop: Well, before you leave... I got the first couple of stages of the pad/align stuff working at the weekend. | 16:48.24 |
| | Now I've got to make it actually do the alignment. | 16:48.37 |
| | oops. scared him off. | 16:49.23 |
| ray_laptop | Robin_Watts: sorry. my laptop decided to reset | 16:56.08 |
| Robin_Watts | np :) | 16:56.25 |
| ray_laptop | The finger is a minor out-patient surgery. The doctor usually does it in the office, but the insurance won't cover that, so I have to go to a surgery center. | 16:57.25 |
| Robin_Watts | so, in your code, you hadn't actually done the alignment had you? | 16:57.33 |
| | What's actually wrong with your finger? | 16:58.03 |
| ray_laptop | Robin_Watts: All I had in my code was a "TEST_ALIGN_MOD_AND_PAD" #ifdef that set the alignment and pad to test values | 16:58.41 |
| Robin_Watts | ray_laptop: Right. I tried that kind of test this morning. | 16:58.56 |
| ray_laptop | I think I was using 5 for pad and 8 for align_mod (3 for log2_align_mod) | 16:59.16 |
| Robin_Watts | I'm using 5 for pad and 6 for align_mod. | 16:59.35 |
| | (3 won't have any effect, as 3 < 4) | 16:59.51 |
| ray_laptop | Robin_Watts: oh, that's a log2 of bits, not bytes ? | 17:00.16 |
| Robin_Watts | No, bytes. | 17:00.29 |
| ray_laptop | log2_align_mod 3 means 8 byte alignment, then ? | 17:01.06 |
| Robin_Watts | oh, sorry, ignore what I said about 3 not having any effect. | 17:01.13 |
| | brain fart. | 17:01.28 |
| ray_laptop | Robin_Watts: 3 is the default on 64-bit linux, iirc | 17:01.42 |
| Robin_Watts | yes. | 17:01.45 |
| ray_laptop | so to test something different (non-standard), you'd want 4 or more | 17:02.08 |
| Robin_Watts | right. I tested with 6. | 17:02.33 |
| | In order to do the alignment I've had to change gx_device_memory a bit, | 17:02.55 |
| | Instead of holding just 'base', I've now got 'unaligned_base' and 'base'. | 17:03.09 |
| | unaligned_base = the thing that's malloced/freed. | 17:03.22 |
| | and base is the aligned version of that. | 17:03.34 |
| ray_laptop | Robin_Watts: I didn't think you needed the aligned base for anything except line_ptrs. Did you find a place that needed it ? | 17:04.32 |
| | everyone is supposed to access scan_lines from line_ptrs | 17:04.52 |
| Robin_Watts | I was assuming that some places might access directly using base and raster. | 17:05.36 |
| | That would make things simpler. | 17:06.23 |
| | Let me park what I have and try to proceed on that basis. | 17:06.35 |
| ray_laptop | Robin_Watts: OK. | 17:06.42 |
| Robin_Watts | Thanks. | 17:06.48 |
| | The garbage collection for this stuff will be 'interesting'. | 17:07.03 |
| ray_laptop | BTW, have you updated the code for cust 801? | 17:07.20 |
| Robin_Watts | ray_laptop: I haven't. | 17:07.33 |
| ray_laptop | Robin_Watts: I would have tended to keep the 'base' the same, and add an 'aligned_base' | 17:07.43 |
| Robin_Watts | ray_laptop: I was working under the assumption that lots of people would be using 'base' to access things, hence I didn't want to cause changes throughout peoples devices. | 17:08.19 |
| | i.e. I was thinking that setup would be the small case to change. | 17:08.44 |
| ray_laptop | Robin_Watts: because is 'foreign_bits' is set, the GC enumerates using mdev->base | 17:08.45 |
| | Robin_Watts: and if we are using 'foreign_bits' (as with the example code that you worked on for the non defunct company) that got band buffers from a call out, do we still use the alignment and pad when setting up the line_ptrs ? | 17:10.57 |
| | Robin_Watts: oops. I had that backwards -- the GC enumerates using mdev->base IFF foreign_bits is false | 17:11.41 |
| Robin_Watts | ray_laptop: create_buf_device can only take 1 pointer in. | 17:11.47 |
| ray_laptop | Robin_Watts: but the question about alignment with foreign_bits is still a question | 17:12.03 |
| Robin_Watts | and that thing might get freed. | 17:12.08 |
| | hence we always have to pass the unaligned version in there, and do the alignment/padding ourself. | 17:12.27 |
| ray_laptop | Robin_Watts: right, but I think that we can just align the line_ptrs (in set_line_ptrs) and that's it | 17:13.11 |
| Robin_Watts | A lot of the time, the alignment and padding will be set to 0, so it won't actually do anything. | 17:13.21 |
| | ray_laptop: Indeed, that's what I'm going to try now, after you've changed my mind. | 17:13.35 |
| ray_laptop | Robin_Watts: it won't be doing anything different than the standard code, that is | 17:13.55 |
| Robin_Watts | ray_laptop: Right. | 17:14.09 |
| ray_laptop | Robin_Watts: and the 'size' needed for a buffer needs to include the extra amount to align the first line, and use the alignment and pad for the rest of the lines | 17:14.49 |
| | (that's in the size_bits func) | 17:15.18 |
| Robin_Watts | yes, I have code for that here. | 17:15.42 |
| ray_laptop | I notice that in gdev_mem_set_line_ptrs, it originally didn't do anything to make sure that the lines started on align_bitmap_mod boundaries. | 17:18.57 |
| | It just assumed that mdev->base (or the base passed in) was properly aligned | 17:19.36 |
| Robin_Watts | Indeed. I am just transplanting that code over from my new parked branch. | 17:20.19 |
| ray_laptop | Robin_Watts: what do you think about adding a 'size' parameter to gdev_mem_set_line_ptrs so it can return an error if it would go past the buffer size (in the default case with line_ptrs_adjacent, that would overlap the initial line_ptrs) | 17:22.18 |
| Robin_Watts | ray_laptop: Why would we need to? | 17:22.42 |
| ray_laptop | Robin_Watts: if someone passes a buffer that is too small (e.g., they haven't use the gdev_mem_bits_size value), it provides an extra check. | 17:23.47 |
| Robin_Watts | People should be using gdev_mem_bits_size. | 17:24.00 |
| ray_laptop | Robin_Watts: agreed. But do they ? By modifying the calling sequence, at least we'll get a compile error (warning?) and be able to check each usage for the way they allocate the buffer | 17:25.22 |
| Robin_Watts | I will ponder on that. | 17:25.39 |
| ray_laptop | but I guess it will be pretty to likely to segfault if we overwrite the line_ptrs | 17:26.20 |
| Robin_Watts | I've been overwriting them all day, and it's been reliably SEGVing :) | 17:26.47 |
| kens | OK I'm off goodnight folks | 17:28.03 |
| ray_laptop | Robin_Watts: it's just when the line_ptrs aren't adjacent, that we may scribble on somebody else's memory | 17:28.26 |
| | Robin_Watts: and those clients are the ones that are less likely to have done things correctly w.r.t. allocating the raster line buffer | 17:30.23 |
| Robin_Watts | ray_laptop: It feels wrong to bend the API for the sake of broken clients. | 17:34.11 |
| ray_laptop | Robin_Watts: OK. I don't feel strongly | 17:35.22 |
| | Robin_Watts: I had honked up my XXXX_Project tree, so I re-loaded it, and loaded your 801.tar.gz on top of it. I fails to buld ramfs.dev. Does that tarball belong on HEAD, or on their code ? | 18:00.03 |
| Robin_Watts | on HEAD | 18:00.13 |
| ray_laptop | Robin_Watts: that would explain it :-/ | 18:00.24 |
| | sorry. | 18:00.27 |
| Robin_Watts | np. | 18:00.30 |
| | How come linux has a pam device by default and windows doesn't? | 18:18.46 |
| mvrhel_laptop | Robin_Watts: so I have two commits in my mupdf repos for you to look over | 18:38.50 |
| | one fixes an issue with windows 8.1 plus some zooming bugs. | 18:39.15 |
| | the other adds printing support | 18:39.21 |
| | the printing support is going to need a little more work, but I wanted to get what I have in place now | 18:39.39 |
| Robin_Watts | So when you zoom a page, you zoom pages +/- 10 from it too? | 18:41.09 |
| mvrhel_laptop | no | 18:41.35 |
| | hold on | 18:41.50 |
| | no | 18:42.48 |
| | that does not do a re-render | 18:42.56 |
| | just gives a size change | 18:43.03 |
| Robin_Watts | but why +/- 10 pages? | 18:43.26 |
| mvrhel_laptop | so that when we do go to that page quickly, we get the thumb or what ever is rendered there scaled properly | 18:43.27 |
| Robin_Watts | why 10 ? | 18:43.27 |
| | If it's just a size change, why not all pages? | 18:43.38 |
| mvrhel_laptop | if I have 1000 pages it seemed excessive to do that every time the scale changed | 18:43.58 |
| Robin_Watts | Ok, so then why not just +/- 1 ? | 18:44.11 |
| mvrhel_laptop | 10 seemed to get one fast enough where by when I started scolling then they were updated | 18:44.14 |
| Robin_Watts | So the danger is that I might scroll quickly forwards and I'd get pages on that hadn't been resized? | 18:44.40 |
| mvrhel_laptop | whew. | 18:44.46 |
| | yes | 18:44.49 |
| Robin_Watts | how would that manifest itself? | 18:44.54 |
| mvrhel_laptop | it just looked funny | 18:44.55 |
| | well the page would come up small and the zoom big | 18:45.05 |
| | the way I have it now, | 18:45.14 |
| | the page comes up proper sized but blurry | 18:45.26 |
| | and then comes in focus | 18:45.29 |
| | as it renders | 18:45.35 |
| | this is clearly dependent up the machine | 18:45.51 |
| | I fooled about on the surface and my PC | 18:46.01 |
| | and decided on the value that I have | 18:46.14 |
| Robin_Watts | So, if we scroll quickly to a page that we haven't done the resize on, it will appear blurry and then refresh to be sharp. | 18:46.54 |
| mvrhel_laptop | this really only comes into play if some one did a resolution change and then started flipping pages fast | 18:46.55 |
| Robin_Watts | That sounds fine. | 18:46.59 |
| | How would that differ from us flipping to a page that we HAD done the resize on? | 18:47.20 |
| mvrhel_laptop | Robin_Watts: no you are a little confused. give me a chance to explain | 18:47.41 |
| Robin_Watts | Sure, sorry, I'm probably being dim. | 18:47.52 |
| mvrhel_laptop | no just asking questions faster than I can type | 18:48.02 |
| | so LOOK_AHEAD which has a value of 1 will prerender at the zoom resolution the pages that are +/- LOOK_AHEAD | 18:48.46 |
| | so when someone flips to the next page, it should already be rendered if they are moving at a reading speed | 18:49.08 |
| | the thumbnails are pre-rendered for all the pages at a fixed resolution | 18:49.33 |
| | and the "images" have a size associated with the thumbnail bitmaps which are the actual page sizes. so if you were to view the thumbnail it would look like the normal page size but a low res blurry version | 18:50.37 |
| | now, when someone does a resolution zoom | 18:50.53 |
| | the thumbnail images are still at the page sizes. | 18:51.06 |
| Robin_Watts | what is a resolution zoom? how does that differ from a normal zoom? | 18:51.38 |
| mvrhel_laptop | but I now go ahead and adjust those thumbnail image dimensions so that they are scaled to the zoom resolution | 18:51.39 |
| | Robin_Watts: so there really are two ways to make the image larger | 18:51.56 |
| | one is to re-render it | 18:52.02 |
| | another is to just change the dimensions | 18:52.11 |
| | and windows does its interpolation | 18:52.18 |
| | did I use the words resolution zoom vs. normal zoom? | 18:52.46 |
| | sorry | 18:52.59 |
| | that should say | 18:53.16 |
| | when someone does a zoom | 18:53.20 |
| | ok. now where was I | 18:53.34 |
| Robin_Watts | sorry, go on. | 18:54.00 |
| mvrhel_laptop | ok. so the LOOK_AHEAD_SCALE just resizes the thumb nails near where we are to the current zoom size so that when the user quickly flips through, the thumbnail sizes match what is going to be rendered | 18:54.48 |
| | and this needs to be more than +/- 1 | 18:55.04 |
| | since we can flip faster than we can render on some devices | 18:55.14 |
| Robin_Watts | ok, so just a sec... | 18:55.22 |
| mvrhel_laptop | at certain large zoom factors | 18:55.23 |
| | that is what I should have said to start with | 18:55.45 |
| Robin_Watts | When you zoom a page, you tell windows that it should display the thumbnails for the pages in a region around the current one at a different scale than before. | 18:56.14 |
| mvrhel_laptop | right | 18:56.26 |
| | as the thumbnail is what is first shown when we go to a page | 18:56.47 |
| Robin_Watts | That doesn't cause the thumbnails themselves to be redrawn, just that the old thumbnails are used at the new scale. | 18:56.50 |
| mvrhel_laptop | yes | 18:56.54 |
| | thumbnail are never redrawn | 18:57.06 |
| | just scaled via windows magic | 18:57.23 |
| Robin_Watts | Right, so what if I flip too fast and I get past that region. Does the thumbnail for the next page appear scaled to the wrong size? | 18:57.36 |
| mvrhel_laptop | yes it would look a little funny if you could get to that point | 18:58.31 |
| Robin_Watts | Right, that was my concern. | 18:58.40 |
| mvrhel_laptop | as you would see the page blurry at normal resolution | 18:58.42 |
| | and then it would scale up to fully resolution not-blurry | 18:58.58 |
| | and that is what this fixes | 18:59.02 |
| Robin_Watts | This commit stops pages momentarily appearing at the non-zoomed resolution if you flip far enough? Or it fixes it so that the pages correct themselves after momentarily being wrong ? | 18:59.55 |
| mvrhel_laptop | Robin_Watts: you will not be able to flip fast and far enough to get to a page that does the jump | 19:00.33 |
| Robin_Watts | mvrhel_laptop: Statements like that always come back to bite me :) | 19:00.52 |
| mvrhel_laptop | as when you flip, it will resize a thumbnail that is +/- 10 pages beyond where you are | 19:01.05 |
| | so in FlipView_SelectionChanged | 19:01.18 |
| | it does an UpdateZoom | 19:01.26 |
| | so with every page fip | 19:01.32 |
| | flip | 19:01.34 |
| | we keep a running window of 10 pages properly scaled | 19:01.48 |
| | actually 21 pages | 19:01.59 |
| Robin_Watts | If it was the case that flipping one page always forced the pages around that new page to be properly scaled, then the window need only ever be +/-1 | 19:02.10 |
| mvrhel_laptop | no | 19:02.16 |
| | that does not work | 19:02.19 |
| | due to the threading | 19:02.27 |
| | while one page is rendering, you can flip do the next | 19:02.37 |
| | s/do/to/ | 19:02.43 |
| | and the next and the next | 19:02.48 |
| Robin_Watts | So the rescale is done when the rendering completes? | 19:03.06 |
| mvrhel_laptop | and this is fired after the selection is changed | 19:03.10 |
| | it may be that +/- 2 would wrk | 19:03.19 |
| | work | 19:03.21 |
| | sorry I was wrong | 19:03.36 |
| | it has to do with the fact that FlipView_SelectionChanged occurs after the selection change | 19:03.55 |
| | let me try 2 for second | 19:04.10 |
| | one is def. not enough though | 19:04.37 |
| Robin_Watts | Ah, so the event you are triggering the rescale on happens AFTER the flip has already happened. | 19:04.50 |
| mvrhel_laptop | yes | 19:04.56 |
| Robin_Watts | That explains why you need more than 1, yes. | 19:05.00 |
| | Now, I've worked on systems such as thing before, and to avoid exactly this sort of problem, they have a 'pre_selection_change' event or something. | 19:05.41 |
| | An event that is called before something is selected. | 19:05.56 |
| mvrhel_laptop | Robin_Watts: unfortunately, the manipulation started etc events for the flipview xaml object does not work so well. | 19:06.58 |
| Robin_Watts | ok, I understand what's going on at least. thanks. | 19:07.54 |
| | 2 would be nicer than 10 if it's safe. | 19:08.10 |
| mvrhel_laptop | yes. let me check that on the surface too | 19:08.21 |
| | oh also I have a fix for pixmap.c | 19:08.35 |
| Robin_Watts | Other than the +/-10 thing that first commit looks fine (at least, as far as I understand it) | 19:09.34 |
| mvrhel_laptop | ok thanks. let me push this other fix too | 19:09.54 |
| Robin_Watts | oh, well, there is some commented out code in there that may want to be deleted. | 19:10.41 |
| | in mupdf_cpp::MainPage::RenderRange | 19:11.43 |
| | but that's a tiny thing. | 19:11.50 |
| mvrhel_laptop | oh ok thanks | 19:12.16 |
| Robin_Watts | similarly in the second commit there is a dead //mm_print.RegisterForPrinting(); in MainPage::InitialRender() | 19:12.40 |
| mvrhel_laptop | I dont see that | 19:12.55 |
| | in RenderRange | 19:12.59 |
| Robin_Watts | //spatial_info_t spatial_info = InitSpatial(1); | 19:13.41 |
| mvrhel_laptop | and RegisterForPrinting has no commented code either | 19:13.42 |
| | oh | 19:14.04 |
| Robin_Watts | void MainPage::RenderRange(int curr_page) | 19:14.04 |
| | { | 19:14.05 |
| mvrhel_laptop | yes | 19:14.05 |
| Robin_Watts | /* Render +/- the look ahead from where we are if blank page is present */ | 19:14.07 |
| | //spatial_info_t spatial_info = InitSpatial(1); | 19:14.09 |
| | and in MainPage::InitialRender() you have: //m_print.RegisterForPrinting(); | 19:14.26 |
| | like I say, these are VERY minor :) | 19:14.33 |
| | There is some wierd indentation in PrintTaskRequested. | 19:15.39 |
| mvrhel_laptop | oh crap | 19:16.11 |
| | those are spaces | 19:16.15 |
| | let me fix that | 19:16.22 |
| | sigh | 19:17.04 |
| | Robin_Watts: so I pushed the one little fix for pixmap.c | 19:18.10 |
| Robin_Watts | mvrhel_laptop: Ah, yes, sure. | 19:18.43 |
| mvrhel_laptop | I will clean up the tab/spacing stuff and remove the dead code | 19:18.50 |
| Robin_Watts | I blame tor7 and his naughty gcc ways :) | 19:18.55 |
| | mvrhel_laptop: All 3 commits look fine to me (other than the indentation etc) | 19:19.10 |
| | I can't claim to understand all the windows printing gubbins, but it seems plausible enough :) | 19:19.36 |
| mvrhel_laptop | Robin_Watts: ok thanks. Should I try to amend the tab/spacing stuff to one of the commits or are you fine with me doing a seperate commit | 19:19.59 |
| Robin_Watts | mvrhel_laptop: It's in "your" windows 8 code, so feel free to do it separately. | 19:20.17 |
| mvrhel_laptop | ok. thanks | 19:20.22 |
| | damn I must have had my project open with the space instead of tab settings at one point | 19:22.49 |
| Robin_Watts | oh, bugger. | 19:33.05 |
| | 2181 diffs in the cluster, so I bmpcmp it and see just 1. | 19:33.29 |
| | I think I need to add psd support to bmpcmp :) | 19:33.41 |
| mvrhel_laptop | Robin_Watts: so +/- 2 works must fine. Thanks for catching that | 19:34.19 |
| Robin_Watts | mvrhel_laptop: Ah, fab. | 19:34.26 |
| | It might be worth a quick comment in there as to why we need +/- 2 rather than +/- 1 | 19:34.45 |
| | bmpcmp does have psd support, it seems. | 19:34.57 |
| | so why isn't that showing up in the cluster... | 19:35.06 |
| ray_laptop | well, the bad news is that it took until 30 min ago to finish my "pre-op". | 21:38.26 |
| | The good news is that I don't need to have the surgery. | 21:38.49 |
| | :-) | 21:38.52 |
| | The best medical procedures don't involve doctors, particularly those with sharp knives ;-) | 21:39.28 |
| Gigs- | they had you ready to go to surgery and all? Or a pre-op consultation? | 21:42.50 |
| ray_laptop | Gigs: it was only a finger, and 'pre-op' is where they have us sign all of the "yeah, I know, I might die or worse" forms | 21:43.47 |
| | Gigs: but instead of getting worse since two weeks ago, the little bump on my finger almost went away, so he recommended "let's wait". Fine by me! | 21:44.53 |
| Gigs- | I might need surgery on one of my fingers. I blew up a gun. | 21:46.00 |
| ray_laptop | Gigs-: sorry to hear that :-( | 21:47.31 |
| Gigs- | it's not bad, just the knuckle got kind of screwed | 21:48.23 |
| ray_laptop | guns are safest kept away from hands, IMHO. Preferably locked up somewhere. | 21:48.37 |
| Gigs- | I was working on developing a completely new load, so it was risky | 21:48.57 |
| ray_laptop | Gigs-: yikes | 21:49.20 |
| Gigs- | I was using a powder where you can't necessarily use less because it has a nonlinear pressure curve, and the calculated load and reality didn't line up | 21:49.35 |
| | probably should have used some kind of remote firing set up | 21:49.51 |
| | anyway the gun wasn't badly damaged except for the bolt face, it was a strong gun, but my knuckle got hit by something flying out of the bottom | 21:50.56 |
| | I had an xray a couple weeks afterward because it didn't look like anything but a little cut when it happened, the dr said there was a little sliver of something in there but it looked like the bone was healing fine... but then I kept busting it on things | 21:51.45 |
| | having a knuckle swollen tends to cause it to get hit more often it's like a bad loop :) | 21:52.15 |
| | so speaking of breaking things... I seem to have come to an impasse when it comes to redefining deviceN tint transforms | 21:54.14 |
| | if the target colorant is a component in a deviceN space, I'm not really sure how to handle that in a way that doesn't risk "knocking out" other colorants that are members of the same DN space | 21:55.03 |
| | for example Magenta and BrightPink are a DN space... and BrightPink is actually just another name for magenta. If I knock out brightpink in that colorspace, it also knocks out pixels that are brightpink+magenta | 21:56.36 |
| | bah I think I've found a solution but it sucks, isolate each DN colorant by finding the entry for 100% of only that colorant, and then reconstruct the composite color spaces and clip the values, and hope everything was linear. | 22:11.46 |
| ray_laptop | Gigs-: My problem was also the last joint knuckle, and I kept bumping it. In order to forestall surgery for a long as possible, he recommended putting a bandage, or pad on it when I bump it for a 4 or 5 days to avoid bumping it again. | 22:32.27 |
| | Gigs-: using the 100% of a colorant through the tint transform is also what tiffsep does to be construct the "composite CMYK". We also assume linear | 22:33.58 |
| | Gigs-: and when we add in the colorant, we clamp | 22:34.34 |
| | sounds pretty much like what you describe if I read it correctly | 22:34.53 |
| | Note that we rely on tiffsep maintaining the N colorants in separate planes, so any overprint "knockout" will properly erase or leave the underlying similar component (BrightPink or Magenta), then we can scale the BrightPink by whatever CMYK 1005 tint transform is, and add it in with clamping | 22:37.50 |
| | s/1005/100%/ | 22:38.13 |
| | Gigs-: but if you are trying to fiddle tint transforms in order to "adjust" colorants so they will look right when rendered using the tint transform, and not using all N colorant planes, I don't think you will ever get there. | 22:40.03 |
| | Sort of what mvrhel_laptop went through with SimulateOverprint | 22:40.34 |
| | you can get close | 22:40.44 |
| | mvrhel_laptop: cust 532 is coming in with some problems/questions with the older (8.72++++) code that uses the CMYK->RGB device link hack. I'll check it out and chat with you after I have cogent quesions. | 22:43.25 |
| | probably tomorrow | 22:43.35 |
| mvrhel_laptop | ray_laptop: ok | 23:38.29 |
| | Forward 1 day (to 2013/11/05)>>> | |
IRC Logs