Re: [Hcfr-developer] Meter matrix code thoughts

[John A. <jo...@th...>]

Hmmm, i can certainly see the benefit of starting again, i could swerve the backwards compatibily issue by converting the existing hcfr files to ccmx. 

John

On 1 May 2012, at 14:20, "Ian" <pb...@be...> wrote:

> 
> I think it's definitely better to use the ccmx file format for matrices. 
> We've already got the code to handle it - the CGATSFile class I added is 
> exactly that.  The CCSS implementation is logically just a subset case 
> of matrix correction, and what we've done there is to move the code for 
> it into the meter class itself so that any readings return an adjusted 
> XYZ value requiring no further treatment. It makes sense to do the same 
> thing with the rest of the matrix adjustment code...
> 
> IMHO all of the current matrix correction code should be ripped out and 
> replaced with matrix correction code that stores and reads the matrices 
> from ccmx files and has all of the matrix handling code in the meter 
> class itself. The code to do this should be very similar to the spectral 
> sample code.
> 
> On 01/05/2012 10:01, John Adcock wrote:
>> I've been looking through the code that works out and applies the meter adjustment matrices for colorimeters and before I make some wholesale changes I thought I'd ask first if there was any reason not to proceed.
>> 
>> 1) The meter adjustments matrix is currently held as a global within the libHCFR\color.cpp code and needs to be set before sensor readings are converted to XYZ values.  This seems like a bad idea and will hamper my future plans to be more specific about the colour types used.
>> 2) The default meter matrix is specific to the HCFR meter which seems to return results not as XYZ but as raw sensor readings, this to me breaks the encapsulation of the meter classes which should IMHO return adjusted XYZ values.
>> 3) The current code for generating adjustment matrices requires new measurements, this seems a bit pointless and makes repeatable testing harder
>> 4) The file format for the matrices is thc which is basically the chc format with a different extension, ccmx would be easier as this is human readable
>> 5) The current code for generating matrices doesn't seem to work with my meters and I don't think will work if there is already a matrix loaded.
>> 
>> My plan would be to move the meter adjustment code inside the meter classes so that the return from a meter read is an adjusted XYZ value.  I'll delete all the libHCFR\color.cpp code dealing with these matrices. Then I'll look at updating the generation code firstly to take the readings from the previously taken ones rather than creating new ones and also to chain the matrix correctly. I'll leave the file formats the same initially but would plan to support ccmx at some point.
>> 
>> Does this sound reasonable? Any other thoughts?
>> 
>> John
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Hcfr-developer mailing list
>> Hcf...@li...
>> https://lists.sourceforge.net/lists/listinfo/hcfr-developer
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Hcfr-developer mailing list
> Hcf...@li...
> https://lists.sourceforge.net/lists/listinfo/hcfr-developer
>