[argyllcms] Re: Misc questions about argyllcms tools
- From: Frédéric <frederic.mantegazza@xxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sat, 4 Feb 2006 12:10:52 +0100
On Samedi 04 Février 2006 03:24, Graeme Gill wrote:
> Hmm. I guess I wasn't expecting anyone to leap into the middle of the
> pool straight off. At the current point in time, only a single headed
> configuration is supported - sorry about that! (I'll update the
> documentation to reflect this current limitation.)
>
> Even if I expanded the software to be aware of multiple screens (which I
> was intending to do at some later stage), I'm not sure this will help
> you a great deal, as (from a lot of discussion I've read on the
> colorsync list), there are currently issues with operating system
> software, video card drivers, and video cards supporting different LUT
> on two screens. Apparently, it works sometimes on OSX, and very rarely
> on MSWindows. I don't know where X11 stands in this regards, and I'm not
> currently is a position to test it easily.
>
> I'm also under the impression that X11 has two ways of doing multiple
> screens, one of which makes it difficult to detect what display things
> are on.
>
> Can you set your DISPLAY variable (within the shell you're running
> Argyll from) to point at the CRT ? If you can, then running
> dispcal/dispread should wind up on the right screen. It certainly
> won't work if the two screens appear as one to the utilities.
As I only need to calibrate my CRT, I patched the dispwin.c file to force a
virtual screen width in order to get the patches displayed at the center
of the CRT screen (line 119 and following).
A good solution could be to provide cli options to let the user enter the
position and size of the color patches...
> > To make some more tests, I reduced the resolution of the CRT screen,
> > so patches are now displayed at the right of the LCD panel.
> >
> > 2) If the brightness of the LCD is too high, I get the following error
> > during 'dispread' use:
> >
> > Sample read failed due to misread
> >
> > If I reduce the brightness (3 or 4 levels), it works. Why? Could it be
> > a hardware problem?
>
> Sounds like it. I was under the impression that the DTP92 is only
> suitable for CRT displays though. I believe that the DTP94 works
> with LCDs (I don't have one, and I think it is USB, although it might
> do serial as well.) I've never tried using the DTP92 on an LCD,
> I've used the Spectrolino on an LCD, which works for both.
>
> > 3) During 'dispcal' calibration, a lot of patches remain green. And
> > the calibration is totally wrong.
>
> Which patches are you talking about ? The test patches ? What do you
> mean "remain" ?
>
> The test pattern starts out with extreme devices values (RGB white &
> black), and then does a series of neutral (or near neutral ramps), that
> should improve with each round.
>
> > Also, if I use 'dispread' with a .cal file, I
> >
> > get the following error:
> >
> > Dispread: Error - docalibration failed with return value -1]
>
> This indicates you had the -a flag set. If you #define DEBUG in
> dispsup.c, recompile and re-run, you might get more detailed error
> information.
You where right: the DTP92 only works on CRT. With patches on the CRT, all
is now working fine. I attached a quick made profile of my CRT. Does it
look like a correct profile ? (it is named LCD, but it is my CRT...)
> > 4) Is there a way to reset the LUT values after 'dispread' have
> > modified them ?
>
> It shouldn't leave them in too poor a state. In the next release there
> is a new utility "displin" that creates a linear ramp .cal file, that
> can then be fed back into dispread, to reset the display LUT values, and
> you can then kill dispread, to reset the display. (Attached is a linear
> .cal file).
Thanks from the .cal file.
> Again, I'm not sure if I can help you, since this isn't my build script.
> If you were attempting to compile using JAM, I could probably steer you
> in the right direction.
>
> > Tools from the binary package works fine.
>
> Since I compiled these, I might be able to help you if they were
> misbehaving.
Compilation with jam works, but I had add '-f ../Jambase' option...
> If we can get that far, it might be possible to work on how to access
> each screen individually.
Great if you can, but as I said, I only care about the CRT, used to display
the pictures. The alternate solution I proposed (option to let the user
give the position and size of patches) is OK for me.
Guys, thank you very much for your help :o)
Regards,
--
Frédéric
http://www.gbiloba.org
Other related posts:
