Hi Daniel,
I am suffering from the Bits# with Mountain Lion. Great to
see you made it to work for cLUT animation.
I didn't see any change on the "red-scale" T-Lock image
when it was dragged onto the secondary screen. I have an
iMac of Mountain Lion equipped with an ATI Radeon HD 6770M
graphics card. It seems the T-Lock is not working properly
perhaps because of the unintended temporal dithering. And
I failed to downgrade the kernel to 32-bit, as you already
mentioned.
Could you please share your example code and how you fix
the problem? Thanks a lot!
Min
--- In psychtoolbox@yahoogroups.com,
Daniel Baker wrote:
>
> Hi again,
>
> I have now made substantial progress with the Bits#,
and have T-lock
> working for LUTs and DIO/goggles. I'd be happy to
provide example code
> to anyone else attempting this.
>
> In Bits++ mode I can create my own T-lock code and
embed it in an image.
> But in Mono++ mode this doesn't work, because the
image has to be
> greyscale, and PTB converts it to the correct format
(e.g. 2 byte
> greyscale precision + overlay). I can use the
DIOCommand method instead
> to send signals to the pins of the 25-pin I/O port,
which works
> perfectly for bits 1-10 of the 2-byte data/mask
parameters (tested with
> oscilloscope).
>
> However, I would like ideally to send a digital pulse
out of the BNC
> digital trigger port. This is encoded by bit 16 of
the data/mask
> parameters (the Bits# manual says bit 15, but it's
wrong). I'm guessing
> that the fact that Mono++ is only 14 bits means that
the two MSBs get
> automatically lost, meaning that the port is
effectively disabled in
> this mode. It works fine in Bits++ mode using a
manual T-lock.
>
> As far as I can tell, the BitsPlusDIO2Matrix command
is not removing any
> data, and the glDrawPixels function just blits
straight to the screen in
> RGB format. This suggests to me that the bit-loss is
intrinsic to the
> Mono++ mode (i.e. the Bits# itself deletes those bits
before checking
> the T-lock code). Is this likely to be an intractable
problem, or can
> anyone think of a workaround?
>
> Many thanks,
>
> - Daniel
>
>
> On 17/02/2013 23:03, Mario wrote:
> >
> >
> >
> > --- In psychtoolbox@yahoogroups.com
> > , Daniel Baker wrote:
> > >
> > > Hi Mario,
> > >
> > > Yes, you're right, it's an Intel card,
which I gather is not
> > possible to
> > > un-dither at the moment. If you find a
workaround please let me know.
> > >
> >
> > On my request CRS implemented a similar video
readback interface in
> > the Bits# as we have on Datapixx et al. I also
got a Bits# from them
> > for christmas, but haven't had time to play with
it. I assume i will
> > be able to port our Datapixx lut tweaking
routine to the Bits#, to
> > automatically fix the clut for use with Apple's
broken "operating
> > system", that would be the workaround once done.
Upgrading your os to
> > Linux would probably be another option.
> >
> > However, so far Intel gpu's are not tested for
compatibility with high
> > precision display modes at all, because only 3
years ago using them
> > for such tasks would have been mission
impossible. The current Intel
> > HD hardware should be capable of supporting it,
although at lower
> > speed than Nvidia or AMD parts. In the end the
quality of their
> > graphics drivers will decide if they are already
viable for such tasks.
> >
> > Have you tried BitsPlusIdentityClutTest, cycling
through different
> > CLUT if one fits? Did all fail?
> > We don't have custom made lut's for intel yet,
because in the past
> > that would have been pointless, and atm. i don't
have any intel card
> > with an external digital output that would allow
testing this.
> >
> > > I also have a recent MacbookPro, which does
have an Nvidia card.
> > William
> > > Beaudot produced a 64 bit version of
NVinject, which successfully
> > > deactivated the dithering under Mountain
Lion. The T-lock codes work
> > > fine for LUT loading on this machine. I'm
still having trouble getting
> > > the goggles working, but I'm sure I'll get
there.
> > >
> >
> > Can you send me that NVinject for inclusion?
Actually, do we include
> > the 32-Bit version at the moment, or just
provide it for download
> > somewhere?
> >
> > ciao,
> > -mario
> >
> > > Cheers,
> > >
> > > - Daniel
> > >
> > >
> > > On 15/02/2013 16:38, Mario wrote:
> > > >
> > > >
> > > >
> > > > Does your Mac Mini have a NVidia
graphics cards? Apples online shop
> > > > indicates current Mac Mini's have
Intel HD-4000 cards, not NVidia's?
> > > >
> > > > -mario
> > > >
> > > > --- In psychtoolbox@yahoogroups.com
> >
> > > > , Daniel Baker wrote:
> > > > >
> > > > > Dear all,
> > > > >
> > > > > Has anyone had any luck getting
the Bits# to work properly on a
> > current
> > > > > mac running Mountain Lion? (I'm
using a Mac Mini, purchased last
> > > > month).
> > > > > I can get basic functions fine,
but anything requiring T-lock is
> > > > totally
> > > > > non-functional.
> > > > >
> > > > > I have tried all the suggestions
in the Wiki for disabling dithering
> > > > > etc. The NVinject.kext workaround
produces the following errors, I
> > > > think
> > > > > because Mountain Lion does not
support a 32 bit kernel (e.g. see
> > > > >
> > > >
> > http://apple.stackexchange.com/questions/58340/booting-mountain-lion-in-32-bit-mode):
> > > > >
> > > > > 14/02/2013 10:56:53.888
com.apple.kextd[12]: Can't load
> > > > >
/System/Library/Extensions/NVinject.kext - no code for
running
> > kernel's
> > > > > architecture.
> > > > > 14/02/2013 10:56:53.890
com.apple.kextd[12]: Load com.nvinject
> > failed;
> > > > > removing personalities from
kernel.
> > > > >
> > > > > I'm guessing the only solution
will be to parallel install or
> > downgrade
> > > > > to Lion or Snow Leopard, but if
anyone has any suggestions please
> > > > let me
> > > > > know.
> > > > >
> > > > > Thanks in advance,
> > > > >
> > > > > - Daniel
> > > > >
> > > >
> > > >
> > >
> >
> >
>