| | <<<Back 1 day (to 2013/11/12) | 2013/11/13 |
| Robin_Watts | mvrhel_laptop: You here? | 00:29.23 |
| mvrhel_laptop | yes | 00:29.28 |
| Robin_Watts | So if I'm going to start doing this example device tomorrow... | 00:29.43 |
| | what should the colorants be called? | 00:29.50 |
| mvrhel_laptop | Artifex Green and Artifex Orange | 00:30.03 |
| Robin_Watts | ArtifexGreen ? i.e. no spaces? | 00:30.21 |
| mvrhel_laptop | that is fine | 00:30.33 |
| Robin_Watts | I'll use whatever you prefer, I just didn't know if we coped with spaces or not. | 00:31.05 |
| | I'd guess not. | 00:31.07 |
| mvrhel_laptop | I think we do | 00:31.16 |
| | but perhaps not | 00:31.19 |
| Robin_Watts | And what format should the device actually output? | 00:31.34 |
| | psd ? | 00:31.38 |
| mvrhel_laptop | Actually I am pretty sure spaces are fine | 00:31.46 |
| Robin_Watts | The problem with .psd, IIRC, is that it's a planar format. | 00:32.13 |
| mvrhel_laptop | psd is the easiest to view and it lets us do regression testing | 00:32.14 |
| | isnt the customers device a planar device? | 00:32.30 |
| Robin_Watts | process_page naturally produces bands of data. | 00:32.33 |
| | so outputting 6 planar files is very natural. | 00:32.57 |
| | Outputting 1 file that contains 6 planes in sequence is harder. | 00:33.20 |
| mvrhel_laptop | I see | 00:33.27 |
| Robin_Watts | cos I need to buffer the planes somewhere. | 00:33.28 |
| | Unless I seek in the output routine... | 00:33.41 |
| mvrhel_laptop | right | 00:33.51 |
| Robin_Watts | I guess I can do that. I know how big all the planes will be. | 00:33.52 |
| mvrhel_laptop | yes | 00:33.57 |
| Robin_Watts | It'll probably bugger up the cluster though :( | 00:34.01 |
| | cos the cluster doesn't like seeking. | 00:34.08 |
| mvrhel_laptop | what do we do with our current psd device? | 00:34.18 |
| | that does 4 planes | 00:34.22 |
| | actual 4 + | 00:34.32 |
| | actually 64.... | 00:34.38 |
| Robin_Watts | I fear that ends up rendering the page 4 times. | 00:34.42 |
| mvrhel_laptop | actually I thing psd is limited to 56 or something | 00:35.02 |
| | ick | 00:35.05 |
| Robin_Watts | oh, actually, I think there may be a SEGV in the psd device when used with NRT > 0 at the moment. I should look into that first. | 00:35.36 |
| | but assuming I fix that... | 00:35.44 |
| | I'll do the device with seeking. | 00:36.07 |
| | I suspect that in the cluster case the seeks will be ignored, and we'll get screwy md5 sums, but that shouldn't matter as they will be consistent. | 00:36.50 |
| | bmpcmp might be broken though. | 00:37.01 |
| | ok, I know what I'm doing then. Thanks! | 00:37.43 |
| mvrhel_laptop | ok | 00:37.56 |
| marcosw_ | henrys: for the logs, the 101.plt problem was solved by the most recent ghostpcl commit. so two bugs with one patch :-) | 04:45.13 |
| mvrhel_laptop | night all | 07:05.28 |
| sebras | tor7: did you resolve your pixelized font problems? | 11:22.45 |
| tor7 | sebras: eh? | 11:24.45 |
| sebras | tor7: the console font problems on your chromebook pixel. | 11:27.08 |
| tor7 | oh, that. no, not worth the effort for the small time frame between the kernel loading the inteldrmfb device and console-setup switching to the correct font. | 11:27.51 |
| kens | <rant> Iinstalled IE 11, and my sidebar stopped working. Visit the MS site 'Microsoft has discontinued support for Gadgets, MS introduced Apps with windows 8.1, use Apps'. Firstly this is a Windows 7 machine, and why does installing a *web browser* remove funcitonality from WIndows ? </rant> | 13:07.08 |
| | Just invested some time in reverting to !E 10 | 13:07.25 |
| sebras | kens: wasn't microsoft forced to separate the browser and the os some time ago..? apparently they never bothered to... ;) | 13:08.33 |
| kens | SO it would appear, NOT impressed.... | 13:09.57 |
| tor7 | kens: it's a shame that microsoft stopped caring about backwards compatibility from Vista onwards... and getting worse every year since. | 13:25.55 |
| | I expect that soon you'll need Wine to run (old) windows apps on windows... | 13:26.42 |
| kens | tor7 Rapidly getting worse. I *like* the sidebar, I use it a lot, they introduced it in Vista and acnned it in 7, we're supposed to use Gadgets instead. Now they've canned gadgets and we're all supposed to use Apps, which as far as I can tell don't work in WIndows Vista or 7..... | 13:26.55 |
| | I have a copy of VMWare, I'm good for the foprseeabel :-) | 13:27.21 |
| chrisl | tor7: isn't there an XP compatibility thingy in Win7 already? | 13:28.18 |
| Robin_Watts | VMWare does this 'fusion' thing on Macs, where you can run windows apps and they appear as native mac ones. | 13:28.24 |
| | is there an equivalent for windows on windows? :) | 13:28.33 |
| kens | Robin_Watts : only WOW | 13:28.40 |
| | chrisl the compatibility is still there, but it doesn't help if MS remove the feature from teh OS :-( | 13:29.03 |
| chrisl | I thought VMware could run "windowless" on all supported platforms...... | 13:29.13 |
| kens | chrisl Does it ? Not sure never tried that. | 13:29.27 |
| | Wasn't even aware it was possible | 13:29.33 |
| tor7 | chrisl: there is, but it's dodgy. lots of pre-win7 software that use 256-color graphics get mangled colors since from win7 onward, explorer.exe periodically overwrites the 256-color palette with garbage. | 13:29.47 |
| chrisl | tor7: Well, being dodgy does surprise me much, coming from Redmond! | 13:30.21 |
| tor7 | Robin_Watts: virtualbox has a 'seamless' mode, where toplevel windows appear as real windows. is that 'fusion' thing something similar? | 13:32.15 |
| chrisl | It looks like VMware's equivalent is called "unity mode"..... | 13:33.49 |
| tor7 | chrisl: we've discontinued our sourceforge presence, right? | 13:33.50 |
| chrisl | tor7: we will do so from the next release | 13:34.11 |
| tor7 | if not, now's a very good time. they've started bundling thirdparty scamware with installers you download from sourceforge... | 13:34.26 |
| kens | Yeah I was about to mention that | 13:34.36 |
| | Somebody else (someone large IIRC) has withdrawn for the same reason | 13:34.58 |
| chrisl | We agree at the last staff meeting to drop it from the 9.11 release - basically so we drop google code and sf at the same time | 13:35.26 |
| | tor7: one thing I need to look into is how to "close" a sourceforge project...... | 13:36.50 |
| iDev | Hey guys, anyone experienced with mupdf 1.3? | 13:41.17 |
| sebras | tor7: is that only windows installers? | 13:41.24 |
| | iDev: many people here are, do ask your question. :) | 13:41.37 |
| iDev | I found out that 1.3 of mupdf supports annotations, but i havent found a clue how to utilize those features yet. Did someone try them already? | 13:44.42 |
| Robin_Watts | iDev: There is code within the android viewer that uses them. | 13:45.16 |
| | what platform are you working on? | 13:45.28 |
| iDev | im working on android, yeah i saw the mupdf app using them but how ..^^ | 13:46.44 |
| | all samples are version 1.1 and are not using annotations | 13:47.43 |
| Robin_Watts | iDev: I don't follow what you mean. | 13:55.24 |
| | If you take the 1.3 release, it has android code in. That code uses annotations. | 13:55.37 |
| | Or you can work from our git repo, which is probably smarter for an ongoing project. | 13:56.24 |
| kens | Hmm I ran a clurster test, and all was well with my change, I commit it, and now I get a bunch of errors :-( | 14:10.42 |
| Robin_Watts | kens: all in p*mraw files. | 14:13.45 |
| kens | Yes, I'm kind of puzzled by that | 14:14.19 |
| | I can't see how my change could have been affected by the device | 14:14.46 |
| | Hmm, they are all at 300 dpi as well | 14:15.11 |
| | I just realised I did update my code before comitting (of course), so perhaps it wasn't me | 14:15.54 |
| | Doesn't look hugely likely though, the prior commits were henry and you | 14:16.37 |
| Robin_Watts | henrys stuff didn't do a full test, as it was a pcl only change, but my stuff should have done. | 14:17.21 |
| | oh. rats. | 14:17.45 |
| | It does look like it was my fault. | 14:17.50 |
| kens | Ah! | 14:17.55 |
| Robin_Watts | but now I am confused. Cos *I* tested and no errors showed up :( | 14:18.06 |
| | but it's clearly my problem to solve, not yours. | 14:18.18 |
| henrys | my change was too easy to break anything. | 14:18.21 |
| kens | That's what I thought, I do look at the cluster runs form other people | 14:18.24 |
| | Is it OK if I leave it toyou then Robin ? | 14:18.42 |
| Robin_Watts | kens: of course. | 14:18.51 |
| kens | Thanks | 14:18.54 |
| Robin_Watts | will look after lunch. | 14:19.51 |
| kens | I'm in no rush :-) | 14:20.01 |
| marcosw | Robin_Watts: your filter=raw cluster run isn't quite working, files with names such as "tests_private__pdf__sumatra__1112_-_drawing_missing_GDI+.pdf.cups.300.1" are included. you need filter=p.mraw syntax | 15:56.48 |
| Robin_Watts | marcosw: It's close enough for Jazz. | 15:57.12 |
| marcosw | Robin_Watts: are you working on the seg faults introduced with a0a9d6746cf2e911c2db54c756e34e9e52c0723a or shall I open a bug? | 16:03.33 |
| Robin_Watts | marcosw: I've just tested a fix. | 16:08.04 |
| | and now it's pushed. | 16:08.19 |
| marcosw | too late, I opened the bug. It will help your "fixed bug count" stats :-) | 16:08.30 |
| Robin_Watts | :) | 16:08.49 |
| mvrhel_laptop | good morning | 16:18.21 |
| kens2 | Morning michael | 16:18.28 |
| mvrhel_laptop | wow bug 694776 kept you a little busy | 16:19.38 |
| kens2 | I doubt itsd finished yet..... | 16:19.59 |
| | The reporter doesn't understand what I'msaying | 16:20.10 |
| mvrhel_laptop | clearly | 16:20.30 |
| kens2 | Oh sorry Michael, I hadn't realised it was assigned to you, I thought it was mine | 16:20.44 |
| mvrhel_laptop | no worry | 16:22.01 |
| chrisl | suspects mvrhel_laptop won't mind not dealing with that reporter! | 16:22.30 |
| kens2 | :-) | 16:24.08 |
| ray_laptop | mvrhel_laptop: Did you see the problem (and my response) from cust 532 ? | 16:24.46 |
| | mvrhel_laptop: they are using that custom hack you came up with to alter CMYK images to RGB | 16:25.24 |
| | Robin_Watts: what is "NPR > 0" in the log message of commit 0c50e7b ? | 16:32.07 |
| kens2 | I'm assuming that's number of rendering threads | 16:32.23 |
| ray_laptop | kens2: maybe so. I've been abbreviating it here as NRT | 16:32.42 |
| Robin_Watts | ray_laptop: TLA overload sorry. | 16:34.30 |
| | I meant NRT. | 16:34.33 |
| ray_laptop | Robin_Watts: is it possible to "amend" a specific commit ? | 16:37.57 |
| | if it's not the most recent ? | 16:38.36 |
| Robin_Watts | ray_laptop: Any amending of any kind will change the hashes. | 16:38.52 |
| ray_laptop | I use commit --amend all the time locally to clean things up before pushing | 16:39.08 |
| Robin_Watts | so the rule is that once we've pushed to golden, it's carved in stone (unless we spot it really quickly :) ) | 16:39.34 |
| | ray_laptop: But if you mean locally, then yes. | 16:39.51 |
| ray_laptop | Robin_Watts: that's what I thought | 16:39.54 |
| Robin_Watts | Suppose I have a set of 4 patches to push, and I realise that I want to fix a typo on the first one. I can do: git rebase -i HEAD~10 | 16:40.28 |
| | and that will show me a list of the last 10 commits, each labelled 'pick'. | 16:40.48 |
| | If I change the one I want to change to 'r' rather than pick (meaning 'reword'), then save the list and close the window, git will pop up an editor for me to change the commit message in. | 16:41.29 |
| ray_laptop | Robin_Watts: in the most recent SEGV fix you also use NPR in the description, but the top line uses NRT | 16:42.36 |
| | Robin_Watts: what does NPR stand for anyway ? | 16:43.02 |
| ray_laptop | guesses Number of Parallel Renderers | 16:43.23 |
| Robin_Watts | ray_laptop: National Public Radio ? | 16:43.43 |
| | It was just a typo. | 16:43.46 |
| ray_laptop | since it's the latest commit on the golden, can d42c775 be fixed ? | 16:44.24 |
| Robin_Watts | I could fix all of them. | 16:44.42 |
| | but anyone that has updated since I pushed will have problems. | 16:44.51 |
| ray_laptop | Robin_Watts: OK. nm | 16:45.12 |
| Robin_Watts | I'm generally averse to force pushing without a really good reason. | 16:45.21 |
| ray_laptop | Robin_Watts: OK. Just asking. | 16:45.40 |
| Robin_Watts | ray_laptop: Can I get your input on something please? | 16:45.40 |
| ray_laptop | Robin_Watts: sure. | 16:45.46 |
| Robin_Watts | in gxclist.c in clist_init_data | 16:45.58 |
| ray_laptop | Robin_Watts: BTW, the color_usage_array stuff doesn't work yet with NRT > 0 | 16:46.18 |
| Robin_Watts | At around line 466, I calculate the line_ptrs_offset. | 16:46.29 |
| ray_laptop | Robin_Watts: I am working on it | 16:46.40 |
| Robin_Watts | I do that by assuming that the line_ptrs will directly follow the bitmap data. | 16:46.59 |
| | but it turns out that this goes wrong in the pattern_accumulator case. | 16:47.18 |
| | In the pattern accumulator case, the bits_size is set to data_size/2 | 16:47.42 |
| | I can't understand the rationale there. Can you enlighten me please? | 16:48.02 |
| ray_laptop | Robin_Watts: let me look. | 16:48.16 |
| | Robin_Watts: sorry. Scott was on the phone distracting me. Looking now... | 16:48.35 |
| chrisl | ray_laptop: Scott wasn't bugging you about e-mail attachments, was he? | 16:49.21 |
| ray_laptop | chrisl: no. his computer is honked up -- doesn't finish rebooting. Don't know why he called me -- he has the local 'geeks' coming out to work on it | 16:50.14 |
| Robin_Watts | ray_laptop: Cos you are "technical" and can therefore diagnose such things over the phone. | 16:51.02 |
| chrisl | ray_laptop: ah, he's been having trouble sending some photos of his new guitar...... | 16:51.13 |
| Robin_Watts | My father in law called me the other week to ask me how to set the temperature on his fridge. | 16:51.22 |
| ray_laptop | Robin_Watts: It seems unsafe for the clist logic to assume where line_ptrs are based on the "usual" case | 16:51.32 |
| Robin_Watts | ray_laptop: Sorry? | 16:51.55 |
| | ray_laptop: say that again using different words. | 16:52.31 |
| | In the pattern accumulator case, we should use different logic for placing the line_ptrs ? | 16:52.58 |
| ray_laptop | the clist_init_data seems (in general) to be very specific to the underlying nature of mem devices. It assumes that the bdev returned by create_buf_device will be a gx_device_memory | 16:55.28 |
| | calling things like gdev_mem_data_size and gdev_mem_bits_size | 16:56.04 |
| Robin_Watts | ray_laptop: OK, I think I've fixed it. | 16:56.05 |
| | I've reverted it so that in the pattern accumulator case, we don't put the line_ptrs into the same block. | 16:56.36 |
| ray_laptop | Robin_Watts: but w.r.t. pattern-clist the clist playback of a pattern clist calls the "main" clist buffer device, so the buffer size and bits size, etc. during writing are arbitrary. The pattern-clist always writes with a single band | 16:58.29 |
| mvrhel_laptop | ray_laptop:I saw your email to 532. So yes it looks like we need to add in the decode logic into the original hack that we did for them | 16:58.48 |
| | I thought that was getting done | 16:59.05 |
| | but perhaps your current fix is sufficient | 16:59.34 |
| ray_laptop | mvrhel_laptop: it handles the Decode polarity OK *after* it converts the CMYK to RGB | 16:59.38 |
| | but the TRC implicit in their CMYK->RGB profile works wrongly because the CMYK is inverted | 17:00.31 |
| mvrhel_laptop | oh yes. the inversion needs to be before we convert with the profile | 17:01.03 |
| ray_laptop | mvrhel_laptop: I just did a hack to test these two files | 17:01.14 |
| | mvrhel_laptop: so now I need to dig into the image plumbing and do it the right way, and that also means I need to be able to "invert" the Decode, but since it is just numbers (not functions) that's straightforward. | 17:02.38 |
| mvrhel_laptop | I wish we did not have custom changes like this in the graphics lib. I think with the current ICC work flow options they can do away with this. | 17:02.51 |
| ray_laptop | mvrhel_laptop: but there's probably some CET or something that has funky Decode arrays :-/ | 17:03.14 |
| | mvrhel_laptop: with 9.x they can have an ICC profile for images, but can it be different for CMYK images specifically ? | 17:04.10 |
| mvrhel_laptop | The reason we had this was so that all the images in the clist would be RGB based, is that correct? | 17:04.27 |
| ray_laptop | mvrhel_laptop: can RGB images use a different profile than CMYK images ? | 17:04.55 |
| mvrhel_laptop | ray_laptop: the can add in a device link profile for CMYK images that will get applied to them and map them to RGB | 17:04.58 |
| | and they can do the same for RGB images if they want | 17:05.55 |
| ray_laptop | mvrhel_laptop: When they ask about 9.x (which they are moving to) I'll need your help on how to specify that | 17:06.30 |
| mvrhel_laptop | ok. it is pretty easy. customer 801 is using it | 17:06.43 |
| ray_laptop | mvrhel_laptop: Len has 9.06 in "engineering test" mode | 17:06.52 |
| mvrhel_laptop | then we can get away from the special hack in the code | 17:07.19 |
| ray_laptop | he ported their device to 9.06 with only a little help from me :-) | 17:07.29 |
| mvrhel_laptop | nice | 17:07.37 |
| ray_laptop | Now I'm trying to convince him to move to 9.10 :-) Uphill all the way :-( | 17:08.08 |
| mvrhel_laptop | I don't understand why | 17:08.26 |
| chrisl | They think it's "safer" to stay with the older version...... | 17:09.26 |
| ray_laptop | mvrhel_laptop: Mostly it's because they have a cumbersome test process that takes a long time, and uses lots of manpower and paper. | 17:09.36 |
| mvrhel_laptop | maybe we should license them our regression process... | 17:10.09 |
| chrisl | Ignoring the fact they pull in a bunch of random patches that we've not tested together....... | 17:10.17 |
| mvrhel_laptop | but I guess their hardware makes that impossible | 17:10.58 |
| | and makes things difficult | 17:11.04 |
| | hence all the paper | 17:11.14 |
| chrisl | It seems crazy that they haven't setup a way to test without using paper..... | 17:11.43 |
| mvrhel_laptop | yes. I am trying to think of a way. One would think you could simulate the print result still | 17:12.14 |
| | at the end of the day you are putting dots on paper. no reason those can't be digital dots in a file | 17:12.49 |
| chrisl | Yeh, I'd expect the hardware to be fairly stable! Test once, and done | 17:13.22 |
| | Of course, it seems even crazier that they effectively can't debug on the target! | 17:13.39 |
| ray_laptop | mvrhel_laptop: well, it is theoretically possible. The code could run and produce an md5 sum from the h/w "Graphic Order List" contents. Once they went through the expensive "paper" process theyd collect their baseline ms5's That way testing of subsequent versions could be automated and just identify differences they'd need to print and verify | 17:13.47 |
| mvrhel_laptop | ray_laptop: sounds reasonable | 17:14.06 |
| ray_laptop | They'd want to run on their target CPU, of course, not an x86 | 17:14.42 |
| mvrhel_laptop | right | 17:14.47 |
| chrisl | ray_laptop: does their ASIC write directly to the drum, or does it render into memory and transfer to the drum? | 17:15.03 |
| ray_laptop | chrisl: drum ? | 17:15.24 |
| | chrisl: They don't "race" the engine, if that's what you are asking | 17:15.44 |
| chrisl | Just if it rendered to memory, they could pull the raster, and push it across the network | 17:16.27 |
| ray_laptop | they render to a bitmap, compress that (using ASIC) and only when they have the entire color corrected halftoned, compressed bitmap do they send the page onwards | 17:16.50 |
| chrisl | Right, so instead of passing the on to the printer workflow, it could be fed back to a host to do bitmap comparisons | 17:17.39 |
| ray_laptop | chrisl: but I'm not sure that the PPC code can see the buffers. It's mostly run by state machines in the h/w | 17:18.15 |
| chrisl | ray_laptop: Sure, but I'm surprised it's not built into the design - I wouldn't have thought it would add to the cost, and would likely save them hundreds of man hours in testsing | 17:19.24 |
| ray_laptop | chrisl: but I think there is a hook (where, if the printer has a disk, they spool the compressed raster to disk) so at that point, you are right, they could access the fully rendered output | 17:19.38 |
| chrisl | Looking at how much time our regression cluster saves us, seems like a no-brainer to me! | 17:20.31 |
| ray_laptop | chrisl: big companies often don't see the value in reducing headcount (until they are forced to). Managers get compensated (partly) for how big their staff is | 17:20.53 |
| chrisl | ray_laptop: keep the same headcount, get faster product turnaround. | 17:21.48 |
| ray_laptop | chrisl: it has to be presented in terms of "improving quality" and "making project schedules more predictable" since last minute fixes can be more quickly and accurately verified | 17:22.14 |
| | chrisl: but maybe I'll see if I can be granted an audience with some of the managers to broach the subject | 17:23.11 |
| chrisl | ray_laptop: well, I'd have thought those were self evident. But then, that's why I struggle to deal with managers - I can't seem to apply "management logic" | 17:24.11 |
| ray_laptop | chrisl: but they'd need to md5 it. Sending it over the network would be MUCH slower | 17:24.31 |
| chrisl | ray_laptop: it would still be *way* faster than paper based testing...... | 17:25.27 |
| ray_laptop | chrisl: yes, probably faster. Definitely more accurate at spotting differences between versions | 17:26.16 |
| Robin_Watts | henrys, ray_laptop, mvrhel_laptop: So I've got the crashes and stuff out of the way, and I'm finally ready to start on "psdhex" or whatever we want to call it. | 17:27.46 |
| chrisl | ray_laptop: but if an inability to debug fully on the target isn't seen as a *major* problem, this type of testing might be hard sell! | 17:27.53 |
| ray_laptop | chrisl: As far as speed, computing an md5 in PPC code for high res raster images would be pretty slow. What they really need is a h/w md5 generator that intercepts the video to the laser | 17:28.23 |
| Robin_Watts | This will be a 6 component planar device that outputs psd files at 8bpc. | 17:28.25 |
| | As such it will not demonstrate the use of SSE. It will not demonstrate the use of the new bandheight constraint stuff. | 17:29.09 |
| ray_laptop | Robin_Watts: right. Using process_page ? | 17:29.11 |
| Robin_Watts | And it will seek during the output phase. | 17:29.30 |
| | ray_laptop: Yes. | 17:29.32 |
| chrisl | ray_laptop: they'd probably not want to spend on extra md5 hardware. OTOH, sending compressed bitmaps over a gigabit network is probably going to be pretty quick.... | 17:30.01 |
| ray_laptop | chrisl: they don't have Gigabit | 17:30.34 |
| chrisl | I'm surprised you can get anything other Gigabit now! | 17:31.33 |
| ray_laptop | chrisl: hmm. If they can plug in a 3Tb HD, that might be big enough to store all of the compressed bitmaps. Then they could just compare the drive contents on some machine | 17:32.06 |
| | some *fast* machine | 17:32.22 |
| chrisl | ray_laptop: I'm sure there are loads of options, if the will was there to pursue it | 17:32.39 |
| ray_laptop | I have no idea how big their average compressed page is | 17:32.58 |
| Robin_Watts | ray_laptop, mvrhel_laptop, henrys: I wish there was a way we could make the device demonstrate more of this stuff. | 17:33.18 |
| mvrhel_laptop | Robin_Watts: yes the SSE stuff would be nice. | 17:34.03 |
| ray_laptop | Robin_Watts: well, you could do 600->300 dpi on all of the planes | 17:34.07 |
| Robin_Watts | If we had a file format that was 4bit interleaved-scanline we could show the SSE off nicely. | 17:34.45 |
| ray_laptop | Robin_Watts: and also you could drop it down to 4-bits per component. Won't look pretty, but... | 17:35.00 |
| Robin_Watts | ray_laptop: Hmm, so a hexachrome device with antialiasing build in? | 17:35.08 |
| nl_ | hi | 17:35.31 |
| ray_laptop | Robin_Watts: when writing the PSD, you'd probably have to xform it back to 8-bit, but so what ? It's just a test device | 17:36.01 |
| nl_ | don't know who chris is overhere... but wanted to thank him for fixing my gs_threadsafe problem even before i could file a bug report :-) | 17:36.04 |
| ray_laptop | nl_: that'd be chrisl | 17:36.23 |
| nl_ | ow hehe | 17:36.29 |
| chrisl | nl_: you're welcome | 17:36.35 |
| Robin_Watts | ray_laptop: psd is a bad choice for the output, really. | 17:36.37 |
| | cos we have to seek to make it work. | 17:36.47 |
| chrisl | nl_: it seems serious enough to jump on it quickly...... | 17:36.56 |
| nl_ | chrisl: all my problems were gone after your fix | 17:36.58 |
| | :-) | 17:37.00 |
| Robin_Watts | which will knacker our cluster use of it. | 17:37.05 |
| nl_ | chrisl: yeah.. almost no image devices.. like png, jpg, etc... worked before the fix | 17:37.45 |
| | all the text was gone | 17:37.49 |
| ray_laptop | Robin_Watts: unless we write temp files for the bands and then collect them in a post-process | 17:38.03 |
| Robin_Watts | ray_laptop: Indeed. | 17:38.12 |
| chrisl | nl_: you should keep an eye out for more problems, though - GS_THREADSAFE is a fairly new feature, and not heavily used | 17:38.13 |
| henrys | I know you guys are very much agains this but simply using their device is the way to go. Tell them to send us changes as they go along, we'll make recommendations and regression test. The goal is to get them shipping and make $ as quickly as possible. I'm not going to argue about it but does everyone understand the "goal"? | 17:38.15 |
| ray_laptop | after all, the pdfwrite/ps2write use lots of temp files until the entire job is complete (all the pages) | 17:38.44 |
| Robin_Watts | henrys: The problem is that their device will probably output direct to hardware rather than to a file. | 17:39.10 |
| kens2 | ray_laptop : much more than that | 17:39.11 |
| chrisl | henrys: surely there is also the goal of showing these new features off to other potential customers, too | 17:39.20 |
| ray_laptop | henrys: I doubt that the s/w is the critical path | 17:39.22 |
| henrys | their device outputs to a file now. | 17:39.28 |
| Robin_Watts | henrys: It outputs to many files now :/ | 17:39.42 |
| nl_ | chrisl: I'll file bug reports when I find any | 17:39.59 |
| | But so far everything seems to work ok | 17:40.08 |
| chrisl | nl_: thanks | 17:40.09 |
| henrys | Robin_Watts: let marcosw figure that out | 17:40.49 |
| Robin_Watts | henrys: If we can't make their device public, then it's no good as an example. | 17:40.56 |
| henrys | overnight it on a single machine if necessary we can test all our files find all sorts of problems undoubtedly and get them on their way. | 17:41.08 |
| | Robin_Watts: like I'm trying to say that is not "the goal" | 17:41.32 |
| Robin_Watts | henrys: It's 'a goal'. just not the only one. | 17:41.50 |
| ray_laptop | henrys: the problems when using their device probably are not going to be specific to files, but to all the various "modes" the device can operate in (all of their custom parameters) | 17:42.18 |
| henrys | Compared with them shipping it pale's in comparison. | 17:42.22 |
| | pales | 17:42.30 |
| Robin_Watts | ray_laptop: yeah, their range of custom parameters looks scarily huge. | 17:42.53 |
| chrisl | henrys: How does our testing their device get them to shipping any quicker? | 17:43.11 |
| henrys | marcosw just finished working on custom testing. | 17:43.46 |
| ray_laptop | henrys: I think what's important is for the relatively new, untested, features that they use get tested -- 'pageneutralcolor' and band skipping based on the color_usage.or bits | 17:44.27 |
| henrys | chrisl: my view is if you test this code now with all our tests you will find lots of bugs - when do you want to find those bugs? Now or when we are critical path? | 17:44.36 |
| ray_laptop | henrys: and making sure that this all works with BGPrint and NRT>0 | 17:45.18 |
| | henrys: and --saved-page=print reverse | 17:45.47 |
| chrisl | henrys: but our testing is regression testing, so we need a "good" base to compare to | 17:45.55 |
| henrys | ray_laptop: that is what marcosw has been working on, setting up those kinds of tests. | 17:46.09 |
| ray_laptop | henrys: IMHO, testing their "fringe" usage is more critical since we put most of this in for them | 17:46.16 |
| kens2 | Goodnight all | 17:46.27 |
| ray_laptop | nite, kens2 | 17:46.33 |
| henrys | chrisl: yup marcosw is going to have to do a visual of a similar device and flag things that are suspicious. He does that a lot. | 17:47.16 |
| ray_laptop | Robin_Watts: so, your device should write 0's for planes that are unmarked | 17:47.48 |
| Robin_Watts | ray_laptop: yeah, I think that testing a device (any device!) that makes use of the same features that they do is going to get us 90%+ of the way there. | 17:47.51 |
| | ray_laptop: Right. | 17:48.03 |
| marcosw | chrisl: running a compare of BGPrint, NRT>0, and --saved-page=print reverse to the standard command line isn't too big of deal (assuming that "print reverse" does what it says I'll have to some additional work, but no more than I've done for other unusual options). | 17:48.04 |
| Robin_Watts | I am going to investigate temporary files so I can avoid seeking. | 17:48.50 |
| chrisl | henrys: I guess I just don't get why 801 warrants such special treatment...... | 17:48.57 |
| ray_laptop | Robin_Watts: and if it has pageneutralcolor, we want to write just K | 17:48.58 |
| Robin_Watts | ray_laptop: I can worry about page neutral color later. | 17:49.28 |
| ray_laptop | Robin_Watts: sure | 17:49.40 |
| henrys | chrisl: because there is significant money involved. | 17:49.46 |
| ray_laptop | Robin_Watts: that's where we could also use SSE in a process_fn to mash the CMYKOG to K using some function that mvrhel_laptop can (easily?) come up with | 17:50.45 |
| Robin_Watts | henrys: Well, the ball is pretty much in their court with the device now. We can offer to regression test new versions if they come back to us with them. | 17:50.52 |
| | ray_laptop: The data is planar, so don't we just ignore CMYOG ? :) | 17:51.17 |
| henrys | Robin_Watts: how we don't have anything set up to test their device⦠like you said. | 17:51.35 |
| Robin_Watts | henrys: When they come back with their device, then we'll figure out how to test it. | 17:51.55 |
| | In the meantime let's test all the stuff that their device will rely on. by writing another device. | 17:52.14 |
| ray_laptop | Robin_Watts: we don't know that pageisneutral until the clist is written. For colors in the clist that are in "source" form, a different device profile can map to K, but if the color was converted when we wrote the clist, the device profile will have used all of the planes | 17:53.25 |
| henrys | Robin_Watts: like I said I won't argue about it but it isn't the best decision to get them shipping. | 17:53.31 |
| ray_laptop | henrys: IMHO, our job is to make sure that the info we provide to their device works correctly. That's where there will be time lost | 17:54.50 |
| | That and making sure that they can readily accept updates from us, which is why moving as much of their customization into their device is key | 17:55.36 |
| Robin_Watts | henrys: So, you think a better plan would be for us to find a way to test the device that we've currently shipped out to them within our cluster? | 17:56.35 |
| ray_laptop | keeping changes out of the graphics lib and, as much as possible, out of custom PS operators is the way we want to lead them | 17:56.38 |
| henrys | Robin_Watts: I do yes, and a much better use of our time. | 17:57.01 |
| Robin_Watts | The first thing they are going to do is to change how our device outputs. | 17:57.21 |
| henrys | Robin_Watts: we'll tell them to retain a debug mode for testing. | 17:58.08 |
| Robin_Watts | At the moment I output pgms from it. That's absolutely no use whatsoever for them in actual production builds. It's purely a 'debug' mode for them. | 17:58.17 |
| ray_laptop | I have to take my twins to the dentist. They have wi-fi there, so I'll be online off and on once I'm there (about 10:30) | 17:58.32 |
| | bbiaw... | 17:59.03 |
| henrys | marcosw could just take on the project of somehow integrating the device in the cluster now and you can continue working on the device. | 17:59.13 |
| Robin_Watts | henrys: I'm not averse to trying to get their device into our testing, but I think that trying to integrate the device *as it is now* will be a huge waste of time. | 17:59.36 |
| | much better for us to make a cut down "public" device that can easily be tested, and shown around, and that will show up problems that we can fix in advance of their real device coming later. | 18:00.36 |
| henrys | I guess I don't understand - the device now generated pgms why is it difficult for marcosw to integrate that? | 18:01.51 |
| Robin_Watts | gs -o out blah blah blah | 18:02.10 |
| | That produces an empty file called 'out'. | 18:02.18 |
| | It produces out.s0, out.s1, out.s2, etc as pgms. | 18:02.34 |
| henrys | Robin_Watts: yes I assume we can't use md5's and stdout. | 18:03.18 |
| Robin_Watts | indeed. | 18:03.54 |
| henrys | Robin_Watts: as a first go we could do a crash test even. Has anyone done that? | 18:05.18 |
| Robin_Watts | henrys: no. | 18:05.34 |
| | or you could give me 24 hours and I could give us something we can actually test properly. | 18:05.51 |
| henrys | Robin_Watts: fair enough | 18:06.43 |
| chrisl | Robin_Watts: does it build on Linux - I seem to remember they asked about that? | 18:07.29 |
| marcosw | as long as we are talking about a nightly/weekly test there isn't any problem with -o out generating out.s0, out.s1, ... I've dealt with stranger stuff in the past. otoh, waiting a few days is not problem, I'm finalizing the win7 regression testing today and am at andevcon all day thursday and friday. | 18:07.34 |
| Robin_Watts | chrisl: I can't think why it wouldn't. | 18:07.54 |
| chrisl | Robin_Watts: Okay, so if it looks like it might take longer to get something clusterable, I've got script here that runs jobs, and checks for seg faults, errors and warnings - I could run that, if it would be useful | 18:09.47 |
| Robin_Watts | chrisl: I have a similar thing here (htmldiff.pl, the precursor to bmpcmp) | 18:11.38 |
| chrisl | Robin_Watts: yeh, I expected that - it was more to spread the effort, if you wanted it done | 18:12.45 |
| Robin_Watts | chrisl: Thanks, I may take you up on it. | 18:12.57 |
| | but then I can break the cluster while Marcos is away :) | 18:13.08 |
| chrisl | Personally, I find it quite hard to work on my main computer when it's running my test scripts...... | 18:13.50 |
| Robin_Watts | mvrhel_laptop: ping | 20:35.45 |
| mvrhel_laptop | Robin_Watts: pong | 20:35.54 |
| Robin_Watts | Can you give me CMYK equivalents for your desired orange and green please? | 20:36.20 |
| mvrhel_laptop | I can make something up for now if you want | 20:36.47 |
| Robin_Watts | I just need values to go into the psd files. | 20:37.04 |
| | We can tweak them later if required. | 20:37.15 |
| mvrhel_laptop | ok. they really should be derived from the alternate color space | 20:37.52 |
| | during the processing | 20:38.03 |
| | like is done with the psdcmyk device | 20:38.16 |
| | oh. I see what you mean | 20:38.42 |
| | actually no | 20:38.46 |
| | hmm. how did I make this work for the psdcmyk device with an N color profile | 20:39.14 |
| Robin_Watts | My device doesn't have equivalent colors | 20:39.16 |
| | the psdcmyk device has an "equiv_cmyk_spot_colors" structure. | 20:39.43 |
| | but these are inbuilt colorants, so wouldn't be in that, AIUI. | 20:39.56 |
| mvrhel_laptop | well, it would be nicer if the colors were not hard wired in the device, but came from the profile itself | 20:40.32 |
| | hold on | 20:40.32 |
| | aha. gsicc_set_devicen_equiv_colors | 20:42.55 |
| Robin_Watts | mvrhel_laptop: Which would require me to have a spot_equivalent_colors structure. | 20:44.18 |
| | I refer the honorable gentleman to the answer given earlier :) | 20:44.32 |
| mvrhel_laptop | yes. which I think you should have | 20:44.35 |
| Robin_Watts | OK, but I'm not adding that at the moment. | 20:44.45 |
| | I'll just fudge some constants in for now. | 20:44.56 |
| mvrhel_laptop | ok. hold on . let me give you something plausible | 20:45.00 |
| Robin_Watts | Thanks. | 20:45.12 |
| mvrhel_laptop | how about G = CMYK [ 100, 0, 100 0] and O = CMYK [0 58 90 0] | 20:46.42 |
| | percentages obviously | 20:47.34 |
| | Robin_Watts: ^^ | 20:47.36 |
| Robin_Watts | ok, thanks. | 20:48.01 |
| | oh, bugger. | 20:54.40 |
| | I haven't got alignment working for page mode devices yet :( | 20:54.49 |
| | mvrhel_laptop: Hmm. Am I right in thinking that the psdcmyk device is suppose to output CMYK + extra channels depending on the spots present in the files? | 21:03.39 |
| mvrhel_laptop | Robin_Watts: yes. but it depends upon a compile time setting too | 21:59.54 |
| Robin_Watts | mvrhel_laptop: I can't made my device output sane psdcmyk's :( | 22:01.05 |
| mvrhel_laptop | so with psdcmyk if LIMIT_TO_ICC is set, then only the spots in the ICC output profile will be output | 22:02.53 |
| | the others will go through the tint transform and the profile | 22:03.11 |
| Robin_Watts | mvrhel_laptop: Don't worry, I'll keep bashing on it tomorrow. | 22:03.22 |
| | mvrhel_laptop: actually... could I beg a favour? | 22:03.57 |
| | Would it be hard for you to print a cmyk + 2 spots psd for me and mail me the .psd file please? | 22:04.32 |
| | You understand how to tickle the device in the right way. | 22:04.47 |
| | That way I can see what a decent file is supposed to look like :) | 22:04.59 |
| mvrhel_laptop | Robin_Watts: Sure | 22:05.03 |
| | i.e. it is not hard. | 22:05.23 |
| | I will have it for you when you wake up | 22:05.28 |
| Robin_Watts | Thanks. | 22:05.33 |
| mvrhel_laptop | have a good night | 22:05.44 |
| Robin_Watts | you too! | 22:05.52 |
| mvrhel_laptop | I am beating on this damn windows 8.1 ui zooming | 22:05.57 |
| | about ready to drop kick my computer | 22:06.04 |
| Robin_Watts | getting anywhere? | 22:06.08 |
| | ah. | 22:06.18 |
| mvrhel_laptop | I am getting close but I find that my fixes break other things | 22:08.10 |
| | trying to simplify stuff too | 22:08.23 |
| | and I am hoping that I can leverage some of this stuff for the desktop version | 22:08.44 |
| | Forward 1 day (to 2013/11/14)>>> | |
IRC Logs