Join Date: Aug 2006
Location: Hobitville, New Zealand
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
You guys beat up on spectracal far to readily, however saying that I have seen the corporate effect and disconnect creep into the development of their product. Something that happens with product/software companies when the point source for income starts coming from bigger paying customers that weren't the startup group, ie enthusiasts like the many who frequent these forums. I used Derek's xls based product back in 2006~2007, I wrote a promotional review of Calman 3.1 that I believe was a catalyst to influence isf and a number of professionals (who weren't already using it) to use calman 3.1, Ironically Datacolor was the only professional and expensive product at that time. If I remember the timeline correctly, I think Chromapure was only in an initial proprietary use at that time. Newer players always seem fresh and new and forwardly responsive in the development cycle, lightspace is now as 3.1 was because Derek was very much point source communication at that time, even though Steve and lightspace started in professional and added consumer/enthusiast more recently. (ignoring the different technology time space we are in). In a few years Steve may be too overwhelmed by workload priorities to frequent forums such as this, something I've heard frequently, who has time for that!.
I write a little bit of software for scientific research with dataloggers, measurement systems with all sorts of sensors, I think it can be a little simplistic to think that a little code change in one area is easy. It might be or it might not, it really depends on how entwined the logic is. One change could mean one or twenty different alterations. Sometimes you can make a change which may be a correction to a method only to find one has unwittingly chased the original error with adjustments elsewhere in some compounded problem.
Another problem with responsiveness is maybe the fault/bug is just not reported well enough to repeat. The problem of the correction matrix is interesting in that I only could see something if I chased it, forcing an issue. Maybe because I always do my matrix that considers FOV and Y factors so not to over correct, this comes from doing corrections/calibrations on all sorts of sensors. Over correction can place the sensor into less that effective zones and cause artifacts. A bit like the over correction of 20 point adjustments in 8bit environment.
Also some other professionals didn't notice a problem, Chad for example said something of that nature. I note a common factor though, He and I use 1211 spectros and I think for along time he combined it with the i1D3 as do I. The Y actually match reasonably well for these two devices with respect to FOV or more importantly Y levels.
The method should be corrected though, irrespective of anything I noted above, but I also would go further and make a update available for those who have not got their fee up to date for that latest software. At least back to the last year or so time point.
But even if this correction is in place I'd also add that attention needs to made for Y differences, an i1pro(2) or similar level spectro as good as they are for the price point is less than optimum in Y, I believe this is device dependent variability as much as there is variability in any sensor. Although I've stated in the past making a correction profile of any sensor is mostly sound if the environment is static (ie is not moved). Problem is if the reference device is not optimal in one parameter as Y could be then your correction profile is invalid or worse in Y and correct in xy.
Masterpiece Calibration Ltd