[JohnAd]



Quote:
Originally Posted by dml1333 /forum/post/21879859


"Unexpected File Format". Version 2.1 would open the .chc file to view prior calibrations. This one is pretty minor IMHO, so I would suggest putting it low on the list.

I can't reproduce this so if there is a file you have an issue with can you send it to me.


Thanks


John

 

[JohnAd]

Time for another version

http://sourceforge.net/projects/hcfr/files/Windows/3.0.3.0/


This is mainly another attempt at gathering information about the issue people are seeing so improved crash logging and error handling.


I've also integreated the latest argyll code which promises better refresh locking for the colorimeters and which may assist with the low light accuracy issues seem with the i1d3.


There should be fixes for a couple of the crashes reported, it would be very helpful if you could please test any outstanding issues against this version.


Thanks


John

 

[dml1333]

Using the i1D3, 3.0.3.0 takes several seconds longer before the first reading in a sequence (gray scale or primaries, etc.), but gets the first reading wrong. On both gray scale and primary/secondary readings the first reading is barely above zero (.001ftL instead of ~.02-.04 for my Samsung Plasma). This makes for a crazy gamma and non-existent color triangle. I'll go try with my DTP-94 to see if it's only due to changes in the i1D3 Argyll driver.

 

[dml1333]



Quote:
Originally Posted by JohnAd /forum/post/21882993


I can't reproduce this so if there is a file you have an issue with can you send it to me.


Thanks


John

John, regarding the Unexpected File Format when double-clicking on a .chc file, I found that on my laptop, it still had ColorHCFR2.1 associated with .chc files, and at first I couldn't get it to change to HCFR3.x. But after uninstalling and rebooting I finally could get .chc files associated with HCFR 3.0.3 and then it worked fine. So other that the suggestion to automatically register that file association (worth thinking about), there is NO bug.

 

[dml1333]

I tested 3.0.3 with my DTP-94 with both X-Rite and Argyll drivers and no particular issues. Then retested the i1D3 and the results were slightly different. The 0% stimulus on the gray scale measured normally, but the Red (1st measure) in the Primary/Secondary measures was still WAY off. I'm attaching the .chc files as well as the stderr.log files from some of those runs.

 

HCFR3030tests.zip 13.412109375k . file

 

[JohnAd]



Quote:
Originally Posted by dml1333 /forum/post/21883843


o other that the suggestion to automatically register that file association (worth thinking about), there is NO bug.

Great, thanks, I'll look at adding the association to the installer.


Cheers


John

 

[anta1974]

Problem signature:

Problem Event Name: BEX

Application Name: ColorHCFR.exe

Application Version: 3.0.1.0

Application Timestamp: 4f68ea40

Fault Module Name: ColorHCFR.exe

Fault Module Version: 3.0.1.0

Fault Module Timestamp: 4f68ea40

Exception Offset: 000a9692

Exception Code: c0000409

Exception Data: 00000000

OS Version: 6.1.7601.2.1.0.256.4

Locale ID: 1049

Additional Information 1: e325

Additional Information 2: e32556d617456f9ef83281b79349e66e

Additional Information 3: a20b

Additional Information 4: a20b3ce7c0a04d619d05042e6d8f3d9e


Read our privacy statement online:
http://go.microsoft.com/fwlink/?link...8&clcid=0x0409


If the online privacy statement is not available, please read our privacy statement offline:

C:\\Windows\\system32\\en-US\\erofflps.txt

 

[JohnAd]



Quote:
Originally Posted by anta1974 /forum/post/21885192


Problem signature:

Application Version: 3.0.1.0

the latest version should give a crash dump minidump.dmp file which will help solve this.


Thanks


John

 

[anta1974]

3.0.3 all ok, no crash!

Very Very Thanx!!!

When approximately сalculations corrected?

 

[jdbimmer]

Should the i1Pro work in 3.0.3 with the Argyll driver? I am still getting an error:
Code:

icoms: About to open USB port 'usb:/bus1/dev3/ (GretagMacbeth i1 Pro)'
libusb:debug [libusb_open] open 1.3
libusb:error [libusb0_open] libusb0_open: invalid device name '\\\\.\\USB#VID_0971&PID_2000#6&6581723&0&2#{A5DCBF10-6530-11D2-901F-00C04FB951ED}'
Opening USB port 'usb:/bus1/dev3/ (GretagMacbeth i1 Pro)' config 1 failed (Other error) (Permissions ?)icoms: delete called
libusb:debug [libusb_unref_device] destroy device 1.3
libusb:debug [libusb_exit] 
libusb:debug [usbi_remove_pollfd] remove fd 4
libusb:debug [windows_clock_gettime_threaded] timer thread quitting
libusb:debug [libusb_exit] freeing default context

 

[JohnAd]



Quote:
Originally Posted by jdbimmer /forum/post/21888135


Should the i1Pro work in 3.0.3 with the Argyll driver? I am still getting an error:

Thanks for the log, the extra detail should help isolate this one, the error isn't what I thought it was but should be possible to trace back into.


John

 

[JohnAd]



Quote:
Originally Posted by dml1333 /forum/post/21883985


I tested 3.0.3 with my DTP-94 with both X-Rite and Argyll drivers and no particular issues. Then retested the i1D3 and the results were slightly different. The 0% stimulus on the gray scale measured normally, but the Red (1st measure) in the Primary/Secondary measures was still WAY off. I'm attaching the .chc files as well as the stderr.log files from some of those runs.

Thanks for the files and logs, I'll need to check them out properly, I'm a bit busy first half of the week so may take a while.



John

 

[zoyd]

Here is a little more info on the i1pro bug, it appears it's not happy with the driver:

Code:

libusb:debug [libusb_init] 
libusb:debug [init_polling] Will use CancelIo for I/O cancellation
libusb:debug [usbi_pipe] usbi_pipe() called
libusb:debug [usbi_pipe] filedes[1] = filedes[0] = 4
libusb:debug [usbi_add_pollfd] add fd 4 events 1
libusb:debug [windows_clock_gettime_threaded] no hires timer available on this platform
libusb:debug [libusb_init] created default context
libusb:debug [libusb_get_device_list] 
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 0 session_id 0
libusb:debug [usb_enumerate_hub] allocating new device for session 0
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub: \\\\.\\USB#ROOT_HUB#4&24D6EB65&0#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 1 session_id 1
libusb:debug [usb_enumerate_hub] allocating new device for session 1
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor #1 (46 bytes)
libusb:debug [set_device_paths] path (0:1): \\\\.\\USB#VID_0971&PID_2000#5&18F54CB7&0&1#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: libusb0
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_config_descriptor] index 0
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_config_descriptor] index 0
libusb:debug [libusb_unref_device] destroy device 0.0
libusb:debug [libusb_get_device_list] 
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 0 session_id 0
libusb:debug [usb_enumerate_hub] allocating new device for session 0
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub: \\\\.\\USB#ROOT_HUB#4&24D6EB65&0#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 1 session_id 1
libusb:debug [usb_enumerate_hub] using existing device for session 1
libusb:debug [set_device_paths] path (0:1): \\\\.\\USB#VID_0971&PID_2000#5&18F54CB7&0&1#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: libusb0
[B]libusb:warning [set_device_paths] could not match libusb0 device \\\\.\\libusb0-0001--0x0971-0x2000 found devices.[/B]
usb_get_paths about to look through devices:
libusb:debug [libusb_get_device_descriptor] 
usb_check_and_add() called with VID 0x1d6b, PID 0x1
libusb:debug [libusb_get_config_descriptor] index 0
Get config desc. 0 failed
libusb:debug [libusb_get_device_descriptor] 
usb_check_and_add() called with VID 0x971, PID 0x2000
libusb:debug [libusb_get_config_descriptor] index 0
usb_check_and_add() found known instrument
libusb:debug [libusb_unref_device] destroy device 0.0
icoms: There don't appear to be any serial ports
i1pro: About to init coms
i1pro: About to init USB
icoms: About to set usb port characteristics
icoms: About to open the USB port, tries 0
icoms: USB port needs opening
icoms: About to open USB port 'usb:/bus0/dev1/ (GretagMacbeth i1 Pro)'
libusb:debug [libusb_open] open 0.1
libusb:error [libusb0_open] libusb0_open: invalid device name '\\\\.\\USB#VID_0971&PID_2000#5&18F54CB7&0&1#{A5DCBF10-6530-11D2-901F-00C04FB951ED}'
Opening USB port 'usb:/bus0/dev1/ (GretagMacbeth i1 Pro)' config 1 failed (Other error) (Permissions ?)icoms: delete called
libusb:debug [libusb_unref_device] destroy device 0.1
libusb:debug [libusb_exit] 
libusb:debug [usbi_remove_pollfd] remove fd 4
libusb:debug [windows_clock_gettime_threaded] timer thread quitting
libusb:debug [libusb_exit] freeing default context

It looks like you have fixed the problem with low light D3 measurements

, at least I was not able to produce a crash and it properly reads 0.00 it total darkness. I'll do some more plasma stability tests later.

 

[JohnAd]



Quote:
Originally Posted by zoyd /forum/post/21889548


It looks like you have fixed the problem with low light D3 measurements

Thanks for that, We have Graeme to thank for that though, I just merged in his changes, good to hear they are better.


On the i1pro, a couple of things to test if you don't mind, can you try with it plugged directly into the pc and not into any hub and also can you see if spotread works or if that has the same error, the log from spotread with -d2 would be handy if it by some magic does work.


John

 

[zoyd]



Quote:
Originally Posted by JohnAd /forum/post/21889984


Thanks for that, We have Graeme to thank for that though, I just merged in his changes, good to hear they are better.


On the i1pro, a couple of things to test if you don't mind, can you try with it plugged directly into the pc and not into any hub and also can you see if spotread works or if that has the same error, the log from spotread with -d2 would be handy if it by some magic does work.


John

The hub is internal (I'm running this on a MAC via VirtualBox). Spotread works fine as did version 3.0.0.0 Here is the debug output of spot read:

Code:

usb_get_paths about to look through devices:
usb_check_and_add() called with VID 0x1d6b, PID 0x1
Get config desc. 0 failed
usb_check_and_add() called with VID 0x971, PID 0x2000
usb_check_and_add() found known instrument
icoms: There don't appear to be any serial ports
i1pro: About to init coms
i1pro: About to init USB
icoms: About to set usb port characteristics
icoms: About to open the USB port, tries 0
icoms: USB port needs opening
icoms: About to open USB port 'usb:/bus0/dev1/ (GretagMacbeth i1 Pro)'
open() of USB port 'usb:/bus0/dev1/ (GretagMacbeth i1 Pro)' suceeded
Number of configurations = 1
icoms: USB port is now open
icoms: Clearing any USB errors
icoms: usb port characteristics set ok
i1pro: init coms has suceeded
i1pro: About to init instrument

i1pro: Instrument reset with mask 0x1f @ 10 msec
Reset complete, ICOM err 0x0 (0 msec)

i1pro: GetMisc @ 110 msec

i1pro: Read 1 byte from switch hit port @ 110 msec
GetMisc returns 503, 0x11e8, 0xfa00, 0x01, 0x00 ICOM err 0x0 (10 msec)
Firmware rev = 503

i1pro: Read EEProm address 0x0 size 0x2000 @ 120 msec
Read 0x2000 bytes, ICOM err 0x0 (311 msec)
55 key/values in EEProm table
Table entry 0 is Key 0x2715, type 2 addr 0x0, size 4
Table entry 1 is Key 0x271a, type 2 addr 0x4, size 512
Table entry 2 is Key 0x271b, type 2 addr 0x204, size 512
Table entry 3 is Key 0x271c, type 2 addr 0x404, size 4
Table entry 4 is Key 0x271d, type 3 addr 0x408, size 4
Table entry 5 is Key 0x2724, type 2 addr 0x40c, size 4
Table entry 6 is Key 0x2725, type 2 addr 0x410, size 4
Table entry 7 is Key 0x2710, type 2 addr 0x414, size 4
Table entry 8 is Key 0x2711, type 3 addr 0x418, size 4
Table entry 9 is Key 0x2712, type 2 addr 0x41c, size 4
Table entry 10 is Key 0x2713, type 2 addr 0x420, size 4
Table entry 11 is Key 0x2714, type 3 addr 0x424, size 4
Table entry 12 is Key 0x0001, type 4 addr 0x428, size 984
Table entry 13 is Key 0x2afd, type 2 addr 0x800, size 4
Table entry 14 is Key 0x2b02, type 2 addr 0x804, size 512
Table entry 15 is Key 0x2b03, type 2 addr 0xa04, size 512
Table entry 16 is Key 0x2b04, type 2 addr 0xc04, size 4
Table entry 17 is Key 0x2b05, type 3 addr 0xc08, size 4
Table entry 18 is Key 0x2b0c, type 2 addr 0xc0c, size 4
Table entry 19 is Key 0x2b0d, type 2 addr 0xc10, size 4
Table entry 20 is Key 0x2af8, type 2 addr 0xc14, size 4
Table entry 21 is Key 0x2af9, type 3 addr 0xc18, size 4
Table entry 22 is Key 0x2afa, type 2 addr 0xc1c, size 4
Table entry 23 is Key 0x2afb, type 2 addr 0xc20, size 4
Table entry 24 is Key 0x2afc, type 3 addr 0xc24, size 4
Table entry 25 is Key 0x0003, type 4 addr 0xc28, size 1496
Table entry 26 is Key 0x03e8, type 3 addr 0x1200, size 16
Table entry 27 is Key 0x04c5, type 3 addr 0x1210, size 4
Table entry 28 is Key 0x03e9, type 3 addr 0x1214, size 16
Table entry 29 is Key 0x04c6, type 3 addr 0x1224, size 4
Table entry 30 is Key 0x03ea, type 2 addr 0x1228, size 144
Table entry 31 is Key 0x03eb, type 2 addr 0x12b8, size 144
Table entry 32 is Key 0x03ec, type 3 addr 0x1348, size 2304
Table entry 33 is Key 0x0bb9, type 2 addr 0x1c48, size 4
Table entry 34 is Key 0x0bba, type 2 addr 0x1c4c, size 4
Table entry 35 is Key 0x044c, type 3 addr 0x1c50, size 144
Table entry 36 is Key 0x044d, type 3 addr 0x1ce0, size 144
Table entry 37 is Key 0x044e, type 3 addr 0x1d70, size 144
Table entry 38 is Key 0x0fa0, type 2 addr 0x1e00, size 4
Table entry 39 is Key 0x0bbf, type 2 addr 0x1e04, size 4
Table entry 40 is Key 0x0bc0, type 2 addr 0x1e08, size 4
Table entry 41 is Key 0x0bc1, type 2 addr 0x1e0c, size 20
Table entry 42 is Key 0x0bc2, type 2 addr 0x1e20, size 4
Table entry 43 is Key 0x0bc3, type 2 addr 0x1e24, size 4
Table entry 44 is Key 0x0bc4, type 2 addr 0x1e28, size 4
Table entry 45 is Key 0x0bc5, type 2 addr 0x1e2c, size 4
Table entry 46 is Key 0x0bc6, type 3 addr 0x1e30, size 4
Table entry 47 is Key 0x04b4, type 2 addr 0x1e34, size 4
Table entry 48 is Key 0x04b5, type 2 addr 0x1e38, size 4
Table entry 49 is Key 0x04b7, type 2 addr 0x1e3c, size 4
Table entry 50 is Key 0x04b8, type 2 addr 0x1e40, size 4
Table entry 51 is Key 0x04bb, type 2 addr 0x1e44, size 4
Table entry 52 is Key 0x04bc, type 2 addr 0x1e48, size 4
Table entry 53 is Key 0x04bd, type 3 addr 0x1e4c, size 4
Table entry 54 is Key 0x0002, type 4 addr 0x1e50, size 0
Serial number = 307832
Date of manufactur = 6-3-2007
CPLD rev = 999
Capabilities flag = 0x66fc
Physical filter flag = 0x80
High gain         = 4.9524941444
Normal non-lin    = 0.0000000000 1.0102549791 -0.0000004738 0.0000000000
High Gain non-lin = 0.0000000000 1.0217829943 -0.0000010070 0.0000000000
i1pro_restore_calibration restoring from file 'C:/Documents and Settings/xxxx/Ap
plication Data/Cache/color/.i1p_307832.cal'

i1pro: GetMisc @ 451 msec
GetMisc returns 503, 0x11e8, 0xfa00, 0x01, 0x00 ICOM err 0x0 (10 msec)

i1pro: Instrument reset with mask 0x1f @ 461 msec
Reset complete, ICOM err 0x0 (0 msec)

i1pro: GetMeasureParams @ 561 msec
MeasureParam returns 161, 19, 5, 0x04 ICOM err 0x0 (10 msec)
inst_handle_calibrate called
About to call calibrate at top of loop
About to call calibrate at top of loop

i1pro: Set measurement clock mode 1 @ 7561 msec
Set measuremnt clock mode done, ICOM err 0x0 (10 msec)

i1pro: GetMeasureClockMode @ 7571 msec
MeasureClockMode returns 2, 1, (128), 136, 68 0x0 ICOM err 0x0 (0 msec)
Switched to perfect mode, subtmode flag = 0x0

i1pro: SetMeasureParam 29412, 22, 1, 0x06 @ 7571 msec
SetMeasureParams got ICOM err 0x0 (0 msec)

i1pro: Triggering measurement after 10msec delay @ 7571 msec
Scheduled triggering OK

i1pro: Read measurement results inummeas 1, scanflag 0, address 00C855A0 bsize 0
x100 @ 7571 msec
Read 1 readings, ICOM err 0x0 (2053 msec)
(Trig & rd times 0 -10 2043 -10)
Execution time of dark calib time 2.000016 sec = 2063 msec

i1pro: Set measurement clock mode 1 @ 9624 msec
Set measuremnt clock mode done, ICOM err 0x0 (0 msec)

i1pro: GetMeasureClockMode @ 9624 msec
MeasureClockMode returns 2, 1, (128), 136, 68 0x0 ICOM err 0x0 (0 msec)
Switched to perfect mode, subtmode flag = 0x0

i1pro: SetMeasureParam 11765, 22, 2, 0x06 @ 9624 msec
SetMeasureParams got ICOM err 0x0 (0 msec)

i1pro: Triggering measurement after 10msec delay @ 9624 msec
Scheduled triggering OK

i1pro: Read measurement results inummeas 2, scanflag 0, address 00C85FD0 bsize 0
x200 @ 9624 msec
Read 2 readings, ICOM err 0x0 (1642 msec)
(Trig & rd times 0 -10 1642 -10)
Execution time of 2nd dark calib time 2.000016 sec = 1642 msec

i1pro: Set measurement clock mode 1 @ 11266 msec
Set measuremnt clock mode done, ICOM err 0x0 (0 msec)

i1pro: GetMeasureClockMode @ 11266 msec
MeasureClockMode returns 2, 1, (128), 136, 68 0x0 ICOM err 0x0 (0 msec)
Switched to perfect mode, subtmode flag = 0x0

i1pro: SetMeasureParam 4412, 22, 3, 0x06 @ 11266 msec
SetMeasureParams got ICOM err 0x0 (10 msec)

i1pro: Triggering measurement after 10msec delay @ 11276 msec
Scheduled triggering OK

i1pro: Read measurement results inummeas 3, scanflag 0, address 00C85188 bsize 0
x300 @ 11276 msec
Read 3 readings, ICOM err 0x0 (942 msec)
(Trig & rd times 0 -10 942 -10)
Execution time of 3rd dark calib time 2.000016 sec = 952 msec
i1pro_save_calibration saving to file 'C:/Documents and Settings/xxxx/Applicatio
n Data/Cache/color/.i1p_307832.cal'
inst_handle_calibrate done 0x0
Taking 1 measurments in Emission mode called

 

[JohnAd]



Quote:
Originally Posted by zoyd /forum/post/21890093


Spotread works fine

Just to confirm is that the log from the version of spotread shipped with 3.0.3.0 or the argyll version?


John

 

[zoyd]



Quote:
Originally Posted by JohnAd /forum/post/21890553


Just to confirm is that the log from the version of spotread shipped with 3.0.3.0 or the argyll version?


John

That's the Argyll 1.3.7 spotread log, I didn't know you shipped a version as well. I just looked in the 3.0.3.0 directories and couldn't find a version of spotread although there is an empty Tools directory and empty Etalon_Argyll directory.

 

[laric]

Hello Guys,


So long since my last post here !!

I'm pretty happy to see there could be a second life to this project.


As some may know, I'm a member of the original ColorHCFR team and was a bit annoyed seeing this project left as is...


I doubt I can be of any help as my main work was around our own Sensor (the original idea behind this project) and so the sensor embedded code as well as the driver side; also a couple of things on user interface and the build-in patterns utility (that need improvements !).


I'm still in contact with Georges G. the main windows coder that did most of the work (and he is unfortunately unable to spend any time on bug fixing or improvement for quite some time !). He also worked on an Argyll integration to support Color Munki but this beta version is not fully working. Also in contact with the "color" specialist behind this project and could liaise with them if need be... (I've already made them aware).


Last, There is a Cocoa native Mac version available, it is not features equivalent to the Windows one but quite well advanced, I'll try to get the developer to give some inputs if someone want to pursue this work.


We tend to prefer to use native drivers (and have contracts, mainly with XRite) but using Argyll and the free way is an interesting challenge...


Anyway, if you think I can be of any help, feel free to ask...


Long life ColorHCFR

--Patrice (HCFR)

 

[realzven]



Quote:
Originally Posted by laric /forum/post/21893209


Hello Guys,


So long since my last post here !!

I'm pretty happy to see there could be a second life to this project.


As some may know, I'm a member of the original ColorHCFR team and was a bit annoyed seeing this project left as is...


I doubt I can be of any help as my main work was around our own Sensor (the original idea behind this project) and so the sensor embedded code as well as the driver side; also a couple of things on user interface and the build-in patterns utility (that need improvements !).


I'm still in contact with Georges G. the main windows coder that did most of the work (and he is unfortunately unable to spend any time on bug fixing or improvement for quite some time !). He also worked on an Argyll integration to support Color Munki but this beta version is not fully working. Also in contact with the "color" specialist behind this project and could liaise with them if need be... (I've already made them aware).


Last, There is a Cocoa native Mac version available, it is not features equivalent to the Windows one but quite well advanced, I'll try to get the developer to give some inputs if someone want to pursue this work.


We tend to prefer to use native drivers (and have contracts, mainly with XRite) but using Argyll and the free way is an interesting challenge...


Anyway, if you think I can be of any help, feel free to ask...


Long life ColorHCFR

--Patrice (HCFR)

thanks Patrice

 

[JohnAd]



Quote:
Originally Posted by laric /forum/post/21893209


Hello Guys,


So long since my last post here !!

I'm pretty happy to see there could be a second life to this project.

Hello, thanks for the kind wishes and for all the work you guys have put into the project.

Quote:
Originally Posted by laric /forum/post/21893209


As some may know, I'm a member of the original ColorHCFR team and was a bit annoyed seeing this project left as is...

You and any members of the orginal team are of course more than welcome to join/contribute to the sourceforge project. My strong view is that the project is less likely to die again if the source is public.

Quote:
Originally Posted by laric /forum/post/21893209


I doubt I can be of any help as my main work was around our own Sensor (the original idea behind this project) and so the sensor embedded code as well as the driver side; also a couple of things on user interface and the build-in patterns utility (that need improvements !).

Any help in any area would be most welcome. I'm only really scratching the surface of what's in there at the moment.

Quote:
Originally Posted by laric /forum/post/21893209


I'm still in contact with Georges G. the main windows coder that did most of the work (and he is unfortunately unable to spend any time on bug fixing or improvement for quite some time !). He also worked on an Argyll integration to support Color Munki but this beta version is not fully working. Also in contact with the "color" specialist behind this project and could liaise with them if need be... (I've already made them aware).

Thanks for that, one thing that would be nice is to get the latest version of the dev source so that I don't have to spend too much time fixing bugs that have already been fixed and to check that I haven't missed any new features added after the version of the code I started with.

Quote:
Originally Posted by laric /forum/post/21893209


Last, There is a Cocoa native Mac version available, it is not features equivalent to the Windows one but quite well advanced, I'll try to get the developer to give some inputs if someone want to pursue this work.

Thanks, we already have the latest code from Jerome and we have made some moves towards sharing the colour and meter code between the 2 platforms.

Quote:
Originally Posted by laric /forum/post/21893209


We tend to prefer to use native drivers (and have contracts, mainly with XRite) but using Argyll and the free way is an interesting challenge...

Understood, however I'm also a x-rite licensee and my agreements would not cover use within HCFR so I'm being extra careful. One medium term plan is to allow meter plug-ins to a public interface and then if somebody wanted to distribute meter plug-ins based on the native drivers then they would work just fine. I haven't and won't remove the native meter code, if somebody wants to build a version with that code enabled, it's still there.


John