Menu
▾
▴
hcfr-developer
|
From: John A. <jo...@th...> - 2013-04-26 21:15:43
|
It's been a while but I am still around and still keen to help move this project forward. I've been making steady progress merging in the changes from argyllcms 1.5.1 into the git repository in the instlib project in preparation for bringing it across to the hcfr project. Quite a lot has changed and there may well be another round of changes as the default usb access has changed in what looks like a positive way but I'll need to run more tests to see if it actually simplifies anything. Once I have the argyllcms code compiling cleanly (there are still a few warnings still to fix) I'll merge it in and then merge in most of zoyds non-argyll changes, although there are a few I can't yet make sense of that I need to investigate a bit further. Also this mail is partly a ping to the list to see if there is anyone out there, feel free to say hi. John |
|
From: zoyd <zo...@gm...> - 2013-04-26 21:41:11
|
Hi! I'll apologize in advance for my code hacking, let me know if I can help explain any of the changes. -scott On 4/26/13 5:02 PM, "John Adcock" <jo...@th...> wrote: >It's been a while but I am still around and still keen to help move this >project forward. > >I've been making steady progress merging in the changes from argyllcms >1.5.1 into the git repository in the instlib project in preparation for >bringing it across to the hcfr project. > >Quite a lot has changed and there may well be another round of changes as >the default usb access has changed in what looks like a positive way but >I'll need to run more tests to see if it actually simplifies anything. > >Once I have the argyllcms code compiling cleanly (there are still a few >warnings still to fix) I'll merge it in and then merge in most of zoyds >non-argyll changes, although there are a few I can't yet make sense of >that I need to investigate a bit further. > >Also this mail is partly a ping to the list to see if there is anyone out >there, feel free to say hi. > >John > >-------------------------------------------------------------------------- >---- >Try New Relic Now & We'll Send You this Cool Shirt >New Relic is the only SaaS-based application performance monitoring >service >that delivers powerful full stack analytics. Optimize and monitor your >browser, app, & servers with just a few lines of code. Try New Relic >and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >_______________________________________________ >Hcfr-developer mailing list >Hcf...@li... >https://lists.sourceforge.net/lists/listinfo/hcfr-developer |
|
From: John A. <jo...@th...> - 2013-04-26 22:44:50
|
Thanks for all you help and what you've added is a long way from hacking and nicely explained by your git check-in comments. The main ones I felt needed more than a single glance were the libusb initialization as this is bring back code I remember taking out and the isidentity fix which looked like it wouldn't live up to it's name properly. John > -----Original Message----- > From: zoyd [mailto:zo...@gm...] > Sent: 26 April 2013 22:41 > To: Hcf...@li... > Subject: Re: [Hcfr-developer] Progress > > Hi! > > I'll apologize in advance for my code hacking, let me know if I can > help explain any of the changes. > > -scott > > On 4/26/13 5:02 PM, "John Adcock" <jo...@th...> wrote: > > >It's been a while but I am still around and still keen to help move > >this project forward. > > > >I've been making steady progress merging in the changes from argyllcms > >1.5.1 into the git repository in the instlib project in preparation > for > >bringing it across to the hcfr project. > > > >Quite a lot has changed and there may well be another round of changes > >as the default usb access has changed in what looks like a positive > way > >but I'll need to run more tests to see if it actually simplifies > anything. > > > >Once I have the argyllcms code compiling cleanly (there are still a > few > >warnings still to fix) I'll merge it in and then merge in most of > zoyds > >non-argyll changes, although there are a few I can't yet make sense of > >that I need to investigate a bit further. > > > >Also this mail is partly a ping to the list to see if there is anyone > >out there, feel free to say hi. > > > >John > > > >---------------------------------------------------------------------- > - > >--- > >---- > >Try New Relic Now & We'll Send You this Cool Shirt New Relic is the > >only SaaS-based application performance monitoring service that > >delivers powerful full stack analytics. Optimize and monitor your > >browser, app, & servers with just a few lines of code. Try New Relic > >and get this awesome Nerd Life shirt! > >http://p.sf.net/sfu/newrelic_d2d_apr > >_______________________________________________ > >Hcfr-developer mailing list > >Hcf...@li... > >https://lists.sourceforge.net/lists/listinfo/hcfr-developer > > > > ----------------------------------------------------------------------- > ------- > Try New Relic Now & We'll Send You this Cool Shirt New Relic is the > only SaaS-based application performance monitoring service that > delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! > http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > Hcfr-developer mailing list > Hcf...@li... > https://lists.sourceforge.net/lists/listinfo/hcfr-developer |
|
From: zoyd <zo...@gm...> - 2013-04-27 13:18:12
|
On 4/26/13 6:45 PM, "John Adcock" <jo...@th...> wrote: >Thanks for all you help and what you've added is a long way from hacking >and nicely explained by your git check-in comments. Thanks, my first foray into git and I tried to maintain some discipline but I'm sure there are a few edits that made it in uncommented. > The main ones I felt needed more than a single glance were the libusb >initialization as this is bring back code I remember taking out The code as it stood crashed with multiple meters (specifically i1pro 2 + display pro) so I rolled it back to the release 3.0.4.0 version + Graeme's initialization fix. There was also an exception occurring in io.c upon initialization so I had to reinsert libusb_init(0); >and the isidentity fix which looked like it wouldn't live up to it's name >properly. I found it wasn't working when I needed to check the state of the user's calibration matrix so I used some code from here: http://www.engineersgarage.com/c-language-programs/check-if-given-matrix-id entity-matrix that seems to work fine. -scott |
|
From: John A. <jo...@th...> - 2013-04-28 19:02:56
|
> I'm sure there are a few edits that made it in uncommented. Only one or 2 :) , I'll be pretty careful taking things. > > The main ones I felt needed more than a single glance were the libusb > >initialization as this is bring back code I remember taking out > The code as it stood crashed with multiple meters (specifically i1pro 2 + display pro) so I rolled it back to the release 3.0.4.0 version + Graeme's initialization fix. > There was also an exception occurring in io.c upon initialization so I had to reinsert > libusb_init(0); Hmm, I was having issues with multiple meters colormunki and i1d2. Probably there is still something odd going on. >>and the isidentity fix which looked like it wouldn't live up to it's >>name properly. > I found it wasn't working when I needed to check the state of the user's calibration matrix so I used some code from here: Hmm again, I'll do some tests. John |
|
From: John A. <jo...@th...> - 2013-04-29 21:24:57
|
> > > The main ones I felt needed more than a single glance were the > > >libusb initialization as this is bring back code I remember taking > > >out > > > The code as it stood crashed with multiple meters (specifically i1pro > 2 + display pro) so I rolled it back to the release 3.0.4.0 version + > Graeme's initialization fix. > > There was also an exception occurring in io.c upon initialization so > I > > had to reinsert libusb_init(0); > Hmm, I was having issues with multiple meters colormunki and i1d2. > Probably there is still something odd going on. I need this fix with the merged code, still not sure why I removed it but it's back in for now. > >>and the isidentity fix which looked like it wouldn't live up to it's > >>name properly. > > I found it wasn't working when I needed to check the state of the > user's calibration matrix so I used some code from here: > Hmm again, I'll do some tests. Was a bug, I've fixed it without a temporary Essentially all your changes + 1.5.1 argyll are now in the JohnDev branch of git, have a play around and check that I haven't missed anything. Did you play around with any of the argyll 1.5.1 code to fix/improve anything? John |
|
From: zoyd <zo...@gm...> - 2013-04-29 22:21:53
|
Nice work, compiles fine here and I will test it soon with my meters. I did not tweak the 1.5.1 code at all and I don't think it will be necessary since I've used it with my d3 and ArgyllCMS to do all the recent 3dLUT work and I did not find any instabilities. Cheers, -scott On 4/29/13 5:26 PM, "John Adcock" <jo...@th...> wrote: >> > > The main ones I felt needed more than a single glance were the >> > >libusb initialization as this is bring back code I remember taking >> > >out >> >> > The code as it stood crashed with multiple meters (specifically i1pro >> 2 + display pro) so I rolled it back to the release 3.0.4.0 version + >> Graeme's initialization fix. >> > There was also an exception occurring in io.c upon initialization so >> I >> > had to reinsert libusb_init(0); >> Hmm, I was having issues with multiple meters colormunki and i1d2. >> Probably there is still something odd going on. >I need this fix with the merged code, still not sure why I removed it but >it's back in for now. > >> >>and the isidentity fix which looked like it wouldn't live up to it's >> >>name properly. >> > I found it wasn't working when I needed to check the state of the >> user's calibration matrix so I used some code from here: >> Hmm again, I'll do some tests. >Was a bug, I've fixed it without a temporary > >Essentially all your changes + 1.5.1 argyll are now in the JohnDev branch >of git, have a play around and check that I haven't missed anything. > >Did you play around with any of the argyll 1.5.1 code to fix/improve >anything? > >John |
|
From: John A. <jo...@th...> - 2013-04-30 17:44:43
|
On 29 Apr 2013, at 23:25, "zoyd" <zo...@gm...> wrote: > Nice work, compiles fine here and I will test it soon with my meters. I > did not tweak the 1.5.1 code at all and I don't think it will be necessary > since I've used it with my d3 and ArgyllCMS to do all the recent 3dLUT > work and I did not find any instabilities. That's good news, i suspect that there are still some oddities in the wrapper code caused by the argyll api change, i need to review the spotread code in a bit more detail to make sure i haven't missed anything but both of my meters seem to work as expected. John |
|
From: zoyd <zo...@gm...> - 2013-05-04 18:29:22
|
Hi John, Did some quick meter tests with the new code and my D3 works as excepted but the i1pro 2 does not. It's recognized and selectable but the properties page is blank and any calibration or reading operation locks up the program. -scott On 4/30/13 1:22 PM, "John Adcock" <jo...@th...> wrote: > > >On 29 Apr 2013, at 23:25, "zoyd" <zo...@gm...> wrote: > >> Nice work, compiles fine here and I will test it soon with my meters. I >> did not tweak the 1.5.1 code at all and I don't think it will be >>necessary >> since I've used it with my d3 and ArgyllCMS to do all the recent 3dLUT >> work and I did not find any instabilities. > >That's good news, i suspect that there are still some oddities in the >wrapper code caused by the argyll api change, i need to review the >spotread code in a bit more detail to make sure i haven't missed anything >but both of my meters seem to work as expected. > >John |
|
From: John A. <jo...@th...> - 2013-05-06 20:09:18
|
I suppose a clean merge was too much to hope for. Have you got a debug log for the. Does our version of spotread work? John > -----Original Message----- > From: zoyd [mailto:zo...@gm...] > Sent: 04 May 2013 19:29 > To: John Adcock > Cc: Hcf...@li... > Subject: Re: [Hcfr-developer] Progress > > Hi John, > > Did some quick meter tests with the new code and my D3 works as > excepted but the i1pro 2 does not. It's recognized and selectable but > the properties page is blank and any calibration or reading operation > locks up the program. > > -scott > > On 4/30/13 1:22 PM, "John Adcock" <jo...@th...> wrote: > > > > > > >On 29 Apr 2013, at 23:25, "zoyd" <zo...@gm...> wrote: > > > >> Nice work, compiles fine here and I will test it soon with my > meters. > >>I did not tweak the 1.5.1 code at all and I don't think it will be > >>necessary since I've used it with my d3 and ArgyllCMS to do all the > >>recent 3dLUT work and I did not find any instabilities. > > > >That's good news, i suspect that there are still some oddities in the > >wrapper code caused by the argyll api change, i need to review the > >spotread code in a bit more detail to make sure i haven't missed > >anything but both of my meters seem to work as expected. > > > >John |
|
From: zoyd <zo...@gm...> - 2013-05-14 11:51:15
|
Hi John, Was a driver issue on my end. Spotread is working and meter is recognized in hcfr start-up. Still hanging in application so I'll get some debug output. On 5/6/13 4:10 PM, "John Adcock" <jo...@th...> wrote: >I suppose a clean merge was too much to hope for. > >Have you got a debug log for the. Does our version of spotread work? > >John > >> -----Original Message----- >> From: zoyd [mailto:zo...@gm...] >> Sent: 04 May 2013 19:29 >> To: John Adcock >> Cc: Hcf...@li... >> Subject: Re: [Hcfr-developer] Progress >> >> Hi John, >> >> Did some quick meter tests with the new code and my D3 works as >> excepted but the i1pro 2 does not. It's recognized and selectable but >> the properties page is blank and any calibration or reading operation >> locks up the program. >> >> -scott >> >> On 4/30/13 1:22 PM, "John Adcock" <jo...@th...> wrote: >> >> > >> > >> >On 29 Apr 2013, at 23:25, "zoyd" <zo...@gm...> wrote: >> > >> >> Nice work, compiles fine here and I will test it soon with my >> meters. >> >>I did not tweak the 1.5.1 code at all and I don't think it will be >> >>necessary since I've used it with my d3 and ArgyllCMS to do all the >> >>recent 3dLUT work and I did not find any instabilities. >> > >> >That's good news, i suspect that there are still some oddities in the >> >wrapper code caused by the argyll api change, i need to review the >> >spotread code in a bit more detail to make sure i haven't missed >> >anything but both of my meters seem to work as expected. >> > >> >John > |
|
From: John A. <jo...@th...> - 2013-06-12 21:19:52
|
As an update the issue seems to be that argyll now no longer supports the usb access that we have been using and has switched to the libusb project. This means building and signing a whole new set of code as well as updates to drivers at the user end. While this is not a massive amount of work my home server has recently crashed and it's taking me a lomg time to get things back up, once that is done I'll be able to look into this whole thing in more detail. One bit of good news is that the libusb driver stack supports a filter driver which means that we should be able to run hcfr alongside vendor drivers which would be a major user improvement. I know Graham has had some issues with this in the past but I was planning to at least see what worked as in the past I got an i1d2 working with a filter driver and it seemed fine. John > -----Original Message----- > From: zoyd [mailto:zo...@gm...] > Sent: 04 May 2013 19:29 > To: John Adcock > Cc: Hcf...@li... > Subject: Re: [Hcfr-developer] Progress > > Hi John, > > Did some quick meter tests with the new code and my D3 works as > excepted but the i1pro 2 does not. It's recognized and selectable but > the properties page is blank and any calibration or reading operation > locks up the program. > > -scott > > On 4/30/13 1:22 PM, "John Adcock" <jo...@th...> wrote: > > > > > > >On 29 Apr 2013, at 23:25, "zoyd" <zo...@gm...> wrote: > > > >> Nice work, compiles fine here and I will test it soon with my > meters. > >>I did not tweak the 1.5.1 code at all and I don't think it will be > >>necessary since I've used it with my d3 and ArgyllCMS to do all the > >>recent 3dLUT work and I did not find any instabilities. > > > >That's good news, i suspect that there are still some oddities in the > >wrapper code caused by the argyll api change, i need to review the > >spotread code in a bit more detail to make sure i haven't missed > >anything but both of my meters seem to work as expected. > > > >John |
|
From: Graeme G. <gr...@ar...> - 2013-06-13 00:10:54
|
John Adcock wrote: > As an update the issue seems to be that argyll now no longer supports the usb access > that we have been using and has switched to the libusb project. Hi, I'm not sure what you mean by that. Argyll still uses libusb-win32, just like it always has for MSWin. The previous versions did have winusb as an option via libusb1, but I've deprecated the use of libusb0/1, which has eliminated much code and improved ease of support, since that project no longer has to be tracked. I've cleaned it up by updating to the latest libusb-win32version, and simplified things by reducing it to one .inf file. > This means building and > signing a whole new set of code as well as updates to drivers at the user end. While > this is not a massive amount of work my home server has recently crashed and it's > taking me a lomg time to get things back up, once that is done I'll be able to look > into this whole thing in more detail. All the .sys drivers are already signed - an improvement on the previous releases where just the 64 bit driver was signed. Having a single .inf should simplify signing that, if you wish to do so (not strictly necessary, but it makes Win8 installation simpler). There's no .dll to be signed anymore. > One bit of good news is that the libusb driver > stack supports a filter driver which means that we should be able to run hcfr alongside > vendor drivers which would be a major user improvement. I know Graham has had some > issues with this in the past but I was planning to at least see what worked as in the > past I got an i1d2 working with a filter driver and it seemed fine. The libusb-win32 folks don't seem to have confidence in the filter driver. I haven't tried it myself, so I'm not sure why that is, apart from historical problems that seem to have been solved. Graeme. |
|
From: John A. <jo...@th...> - 2013-06-13 06:53:29
|
On 13 Jun 2013, at 00:57, "Graeme Gill" <gr...@ar...> wrote: > John Adcock wrote: >> As an update the issue seems to be that argyll now no longer supports the usb access >> that we have been using and has switched to the libusb project. > > Hi, > I'm not sure what you mean by that. Argyll still uses libusb-win32, I meant what you said, it was vague, we used to use libusb0 and that no longer works as you say > All the .sys drivers are already signed - an improvement on the previous releases > where just the 64 bit driver was signed. Having a single .inf should simplify > signing that, if you wish to do so (not strictly necessary, but it makes > Win8 installation simpler). There's no .dll to be signed anymore. Agree that the dlls are signed but the infs aren't which makes instsllation a pain in x64 from vista up as well as windows 8. Also if I ship a GPL binary I like to be able to build it to ensure I can comply with requests for source. > > The libusb-win32 folks don't seem to have confidence in the filter driver. I haven't > tried it myself, so I'm not sure why that is, apart from historical problems that > seem to have been solved. Thanks for that, as I said it seemed to work for me, there is also a filter installer that could be modified easily to just look for supported usb ids which would make installation somewhat easier. > Graeme. (Sorry for using the wrong spelling) |
|
From: John A. <jo...@th...> - 2013-06-15 08:25:55
|
On 13 Jun 2013, at 00:57, "Graeme Gill" <gr...@ar...> wrote: > John Adcock wrote: >> As an update the issue seems to be that argyll now no longer supports the usb access >> that we have been using and has switched to the libusb project. > > Hi, > I'm not sure what you mean by that. Argyll still uses libusb-win32, I meant what you said, it was vague, we used to use libusb0 and that no longer works as you say > All the .sys drivers are already signed - an improvement on the previous releases > where just the 64 bit driver was signed. Having a single .inf should simplify > signing that, if you wish to do so (not strictly necessary, but it makes > Win8 installation simpler). There's no .dll to be signed anymore. Agree that the dlls are signed but the infs aren't which makes instsllation a pain in x64 from vista up as well as windows 8. Also if I ship a GPL binary I like to be able to build it to ensure I can comply with requests for source. > > The libusb-win32 folks don't seem to have confidence in the filter driver. I haven't > tried it myself, so I'm not sure why that is, apart from historical problems that > seem to have been solved. Thanks for that, as I said it seemed to work for me, there is also a filter installer that could be modified easily to just look for supported usb ids which would make installation somewhat easier. > Graeme. (Sorry for using the wrong spelling) |
Thanks for helping keep SourceForge clean.
X