Menu
▾
▴
hcfr-developer — General Development List
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(14) |
Mar
(25) |
Apr
(16) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
(5) |
Jun
(5) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Avinash M. <av...@no...> - 2014-02-01 07:44:52
|
Thanks for the tip, Graeme. Qt is an excellent cross-platform toolkit and looks like the best tool for the job. It works on Linux, Mac OS X and Windows. I'm wondering whether using Python, PyQt and Qt Creator (which include Qt Designer) might make things simpler than rewriting the UI in C++ once again. There is also the possibility to use Qt Quick<http://qt-project.org/doc/qt-4.8/qml-intro.html> to create the UI using XML and Javascript. The part of the app which uses ArgyllCMS can be left in C++ because, as far as I know, there aren't any Python bindings for it. I'm going to spend a few days investigating and will let you know. Avinash PS: Thanks a lot for ArgyllCMS ;-) On Fri, Jan 31, 2014 at 9:27 AM, Graeme Gill <gr...@ar...> wrote: > Avinash Meetoo wrote: > > > In addition to that, I would like to know if anyone is working on a > native > > Linux port? > > As I understand it, the Mac version is also languishing. My suggestion to > anyone interested in other platforms would be to consider re-writing > the GUI using Qt. This is a non-trivial amount of work, but Qt > is a nice toolkit, cross platform and free. There are some (old) articles > around that provide a rudimentary guide on porting from MFC to Qt > that would be a place to start. "C++ GUI Programming with Qt 4" is > a handy book too, although it's being progressively outdated by > the release of Qt5. > > Graeme Gill. > > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > Hcfr-developer mailing list > Hcf...@li... > https://lists.sourceforge.net/lists/listinfo/hcfr-developer > -- *Avinash Meetoo* *Founder and CEO of Knowledge Seven* Call me on 5493-9394 (Mobile) or 427-9225 (Office) I am on my portal <http://www.avinashmeetoo.com/>, LinkedIn<http://www.linkedin.com/in/avinashmeetoo> , Twitter <http://twitter.com/AvinashMeetoo>, Google+<https://plus.google.com/+AvinashMeetoo> and Facebook <http://www.facebook.com/avinashmeetoo> Visit Knowledge Seven <http://www.knowledge7.com/> and our other websites<http://www.knowledge7.com/network/> |
|
From: Graeme G. <gr...@ar...> - 2014-01-31 05:27:41
|
Avinash Meetoo wrote: > In addition to that, I would like to know if anyone is working on a native > Linux port? As I understand it, the Mac version is also languishing. My suggestion to anyone interested in other platforms would be to consider re-writing the GUI using Qt. This is a non-trivial amount of work, but Qt is a nice toolkit, cross platform and free. There are some (old) articles around that provide a rudimentary guide on porting from MFC to Qt that would be a place to start. "C++ GUI Programming with Qt 4" is a handy book too, although it's being progressively outdated by the release of Qt5. Graeme Gill. |
|
From: Avinash M. <av...@no...> - 2014-01-31 04:22:48
|
Dear all, First of all, thanks a lot for ColorHCFR. I have been using it under Windows for some years now and it's great. It's even working great in Linux thanks to Wine but it does not detect my sensor. I would like to know if someone has managed to run ColorHCFR in Linux (I have Fedora 19) under Wine with a Spyder 3 Express? There is an old post<http://www.homecinema-fr.com/forum/le-colorhcfr/colorhcfr-et-linux-t29838694.html> referring to this kind of issue but things have changed a lot in 8 years... In addition to that, I would like to know if anyone is working on a native Linux port? I suppose this is far from being trivial given the amount of UI code and the maths behind. But I also suppose things are a bit simpler now given that ArgyllCMS is used to access the actual sensors and ArgyllCMS works on Linux. I've cloned the git repo and I'm looking at the code. A proof of concept with only continuous and gray scale measurement would be a great first start... What do you think? Avinash -- *Avinash Meetoo* *Founder and CEO of Knowledge Seven* Call me on 5493-9394 (Mobile) or 427-9225 (Office) I am on my portal <http://www.avinashmeetoo.com/>, LinkedIn<http://www.linkedin.com/in/avinashmeetoo> , Twitter <http://twitter.com/AvinashMeetoo>, Google+<https://plus.google.com/+AvinashMeetoo> and Facebook <http://www.facebook.com/avinashmeetoo> Visit Knowledge Seven <http://www.knowledge7.com/> and our other websites<http://www.knowledge7.com/network/> |
|
From: scott <zo...@gm...> - 2013-11-08 02:34:55
|
Looks like 1.6.1 integration is working well. Is there a way to implement Observer types other than 1931_2 and 1964_10? Those are the only 2 defined with SALONEINSTLIB. Thanks, -scott On 8/18/13 8:54 PM, "Graeme Gill" <gr...@ar...> wrote: >John Adcock wrote: > >> I did had >> a quick look at the 1.6.0 beta code and noticed the new fast access >>method >> for the new meters. Is this driverless, are there likely to be any >> gotchas setting this up. > >Hi, > I'm not sure what you're referring to. > >> The main reason for requiring the commercial MS compiler is that the UI >>is >> based on MFC which is only shipped with MSVC. I have converted a >>project >> from MFC to native Win32 before but it is a long and painful process and >> the graphics and use of the MDI interfere make this pretty daunting. > >Right, I understand. That's too bad - I can't help at all then. > >Any such conversion effort would be better directed at converting >MFC to Qt, to make cross platform support possible. > >Graeme. > > >-------------------------------------------------------------------------- >---- >Get 100% visibility into Java/.NET code with AppDynamics Lite! >It's a free troubleshooting tool designed for production. >Get down to code-level detail for bottlenecks, with <2% overhead. >Download for free and get started troubleshooting in minutes. >http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktr >k >_______________________________________________ >Hcfr-developer mailing list >Hcf...@li... >https://lists.sourceforge.net/lists/listinfo/hcfr-developer |
|
From: Graeme G. <gr...@ar...> - 2013-08-19 00:55:00
|
John Adcock wrote: > I did had > a quick look at the 1.6.0 beta code and noticed the new fast access method > for the new meters. Is this driverless, are there likely to be any > gotchas setting this up. Hi, I'm not sure what you're referring to. > The main reason for requiring the commercial MS compiler is that the UI is > based on MFC which is only shipped with MSVC. I have converted a project > from MFC to native Win32 before but it is a long and painful process and > the graphics and use of the MDI interfere make this pretty daunting. Right, I understand. That's too bad - I can't help at all then. Any such conversion effort would be better directed at converting MFC to Qt, to make cross platform support possible. Graeme. |
|
From: John A. <jo...@th...> - 2013-08-17 10:05:36
|
Opps, forgot to copy list On 17/08/2013 10:41, "John Adcock" <jo...@th...> wrote: >Graeme > >Thanks for the notification. I'll get the code merged in soon. I did had >a quick look at the 1.6.0 beta code and noticed the new fast access method >for the new meters. Is this driverless, are there likely to be any >gotchas setting this up. > >The main reason for requiring the commercial MS compiler is that the UI is >based on MFC which is only shipped with MSVC. I have converted a project >from MFC to native Win32 before but it is a long and painful process and >the graphics and use of the MDI interfere make this pretty daunting. > >John > >On 16/08/2013 01:41, "Graeme Gill" <gr...@ar...> wrote: > >>I've also packaged up the instlib code from the V1.6.0 release and placed >>it >>here <http://www.argyllcms.com/instlib_V1.6.0.zip>. >> >>I think this would be a good point to release a version of HCFR that uses >>the >>latest Argyll instlib code and supports the full range of instruments. >> >>One of the obstacles to building HCFR is that it seems to require a >>commercial >>version of Microsofts's development environment. If there was a Makefile >>provided >>that worked with MingW, it might be possible for a wider group of people >>to help >>in the development. What's involved in moving in that direction ? >> >>Cheers, >> >>Graeme Gill. >> >>------------------------------------------------------------------------- >>- >>---- >>Get 100% visibility into Java/.NET code with AppDynamics Lite! >>It's a free troubleshooting tool designed for production. >>Get down to code-level detail for bottlenecks, with <2% overhead. >>Download for free and get started troubleshooting in minutes. >>http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clkt >>r >>k >>_______________________________________________ >>Hcfr-developer mailing list >>Hcf...@li... >>https://lists.sourceforge.net/lists/listinfo/hcfr-developer >> > |
|
From: Graeme G. <gr...@ar...> - 2013-08-16 01:01:47
|
I've also packaged up the instlib code from the V1.6.0 release and placed it here <http://www.argyllcms.com/instlib_V1.6.0.zip>. I think this would be a good point to release a version of HCFR that uses the latest Argyll instlib code and supports the full range of instruments. One of the obstacles to building HCFR is that it seems to require a commercial version of Microsofts's development environment. If there was a Makefile provided that worked with MingW, it might be possible for a wider group of people to help in the development. What's involved in moving in that direction ? Cheers, Graeme Gill. |
|
From: Martin S. <me...@sc...> - 2013-06-18 14:41:33
|
Hello, first of all a great thanks for all the development work on HCFR. And now my question. Did anyone already has included the ArgyllCMS V1.6 beta code to HCFR? This beta version adds support for a new device (JETI specbos 1211) and it would be great if this device will be supported by HCFR also. My company and I are in contact with Graeme to fully include support for these device, and (except for little bugs) the current beta works. I tried to replace the Argyll code from HCFR (cloned from Git repository) with the Argyll Beta code, but it doesn't work, because I'm not familiar with all the changes needed to merge the Argyll code. So if there is a development version with ArgyllCMS V1.6 I would be pleased to test it and help you as good as I can. Best regards, Martin Schmidt ----- Ursprüngliche Mail ----- Von: "John Adcock" <jo...@th...> An: "Graeme Gill" <gr...@ar...> CC: hcf...@li... Gesendet: Donnerstag, 16. Mai 2013 09:10:19 Betreff: Re: [Hcfr-developer] ArgyllCMS instlib V1.6 changes Thanks a lot for the heads up. John On 15 May 2013, at 10:13, "Graeme Gill" <gr...@ar...> wrote: > Just a heads up that the next release of ArgyllCMS makes a small but significant > change to how ambient readings are reported in instlib. In the past they were > reported as Lux/pi [mW/(m^2.nm.pi) for spectral], in V1.6 they will be reported as > Lux [mW/(m^2.nm) for spectral]. So if you are currently using the ambient readings > and multiplying them by 3.1415926, you can remove the multiplication when using this > new version. > > V1.6 Beta source code is here <http://www.argyllcms.com/Argyll_dev_src.zip> > > Graeme. > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Hcfr-developer mailing list > Hcf...@li... > https://lists.sourceforge.net/lists/listinfo/hcfr-developer > ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Hcfr-developer mailing list Hcf...@li... https://lists.sourceforge.net/lists/listinfo/hcfr-developer |
|
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) |
|
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: 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-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: John A. <jo...@th...> - 2013-05-16 07:41:02
|
Thanks a lot for the heads up. John On 15 May 2013, at 10:13, "Graeme Gill" <gr...@ar...> wrote: > Just a heads up that the next release of ArgyllCMS makes a small but significant > change to how ambient readings are reported in instlib. In the past they were > reported as Lux/pi [mW/(m^2.nm.pi) for spectral], in V1.6 they will be reported as > Lux [mW/(m^2.nm) for spectral]. So if you are currently using the ambient readings > and multiplying them by 3.1415926, you can remove the multiplication when using this > new version. > > V1.6 Beta source code is here <http://www.argyllcms.com/Argyll_dev_src.zip> > > Graeme. > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Hcfr-developer mailing list > Hcf...@li... > https://lists.sourceforge.net/lists/listinfo/hcfr-developer > |
|
From: Graeme G. <gr...@ar...> - 2013-05-15 09:08:34
|
Just a heads up that the next release of ArgyllCMS makes a small but significant change to how ambient readings are reported in instlib. In the past they were reported as Lux/pi [mW/(m^2.nm.pi) for spectral], in V1.6 they will be reported as Lux [mW/(m^2.nm) for spectral]. So if you are currently using the ambient readings and multiplying them by 3.1415926, you can remove the multiplication when using this new version. V1.6 Beta source code is here <http://www.argyllcms.com/Argyll_dev_src.zip> Graeme. |
|
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-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-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-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-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-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: 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: 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-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-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 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 |
1 message has been excluded from this view by a project administrator.
