Conference bgsdev::multimedia_services

485.0. "True-color / psuedo color capture question" by SAYER::ELMORE (Steve [email protected] 412-364-5893) Wed Feb 05 1997 13:00

    It was suggested in the open3d conference that I move this question
    here.  Can someone here help? 
    
    Thanks,
    
    Steve
    
         <<< BGSDEV::DISK$BGSDEVPUBLIC:[NOTES$LIBRARY]OPEN3D.NOTE;1 >>>
                                  -< open3d >-
================================================================================
Note 1231.0  true color capture; using pseudo color default question?    1 reply
SAYER::ELMORE "Steve [email protected] 412-364-58" 57 lines   1-FEB-1997 15:08
--------------------------------------------------------------------------------
    I am not quite sure where to post this question.  I am trying here
    first, but perhaps the X conference is better.  If someone would kindly
    point me to the right place, if not here, I would be grateful.
    
    I received the following mail from a medical imaging OEM.  I don't have
    the expertise to help them.  They are trying to mix pseudo and true
    color together but capture only true color.  Please read on:
    
    
>     Hi.
>
>     We spoke briefly in the hallway while you were at Picker MR
>     a few days ago. 
>
>     I have a problem with a system running Dec UNIX 4.0a and X/Motif.
>     (The problem is not OS or system specific, but it might make a
>     difference later.) 
>
>     The system has a 24 bit color card and the J300 video capture card.
>     We have set up our /usr/lib/X11/xdm/Xservers file to start the system
>     in pseudo color mode even though it is true color capable. We then
>     have some windows on the screen that use true color X visuals and
>     some
>     that use pseudo color. This works OK and saves memory and time when
>     the windows that use the default (pseudo color) visual are moved
>     around.
>
>     The problem comes up when we do video capture. That routine reads
>     pixels from the root window in order to capture the entire screen.
>     The
>     root window defaults to a pseudo color visual,  so the video capture
>     data is only 8 bits deep and is often the wrong value. Somehow we
>     need to
>     read the data from a source that has the full 24 bit pixels. 
>
>     Video capture works OK if we don't force the default visual to be
>     pseudo color, since then the root window comes out as true color and
>     the captured data looks fine. However, then we pay a price in
>     performance and memory usage since all our pixmap data triples in
>     size (from 8 to 24 bits). This can be 100s of megabytes in some
>     cases.
>
>     So, my problem is:
>
>        How can I read 24 bit pixel data from the frame buffer for video
>        capture when the X root window is set up with an 8 bit pseudo
>        color
>        visual? Is there a way to read directly from the frame buffer and
>        bypass X altogether ?
>
>
>     I hope this explanation makes some sense. Please let me know if you
>     have any ideas about this, or other sources I might try for help.
>
>       Thanks.
>               Don Russell
    
    

    If no one can answer directly, can someone point me at an someone who I
    might speak with?
    
    Thanks, 
    Steve
    
    Cross posted - open3d, x, multimedia_services

The obvious folks to speak with would be the ones who man
the support center that your customer has their support
contract with.

Having said that, there is no inherent problem with 
reading full color pixel data from the J300 ever because
its frame store is entirely separate from the graphics
frame store (as I stated in the Open3D conference).

The problem that you describe is being caused by the
application program, but you don't say what the application
is.  AlphaVCR never does more than 8 bit captures, so
that's not it.  vidstreamin is provided in source
form so the customer can change any behavior that they
don't like there.

What application are they having problems with?

Tom

    I guess I'm in an awkward way.  This is a custom X application in the
    medical imaging industry.  All he wants to do is capture the screen
    (not window) image and print it, but not lose the true-color window.  I
    didn't think the support center could advise on programming techniques. 
    I'll try them, but I suspect the support folks may come back into these
    conferences to ask.  Perhaps not!

    I'll also ask the customer to look at the example files again.  But,
    when I sent your (edited) response from the open3d conference, he still
    thinks this is a X issue.  His reply:



    >Thanks for letting me know what's going on.
    >
    >I think this really is an X or a graphics frame buffer issue rather
    >than a J300 specific question, but maybe someone in the J300 group will
    >have an idea for a solution.
    >
    >-- 
    >+------------------------------+-------------------------------+
    >| Don Russell                  |   Internet: [email protected] |
    >| Picker International         |   Voice: (216)-473-5726       |
    >| 5500 Avion Park Drive        |   Fax:   (216) 473-5728       |
    >| Highland Heights, Ohio 44143 |                               |
    >+------------------------------+-------------------------------+

    He knows it's a (his) programming inexperience.  He was just looking
    for some advice.  [They buy about $4M worth of workstations from us.]

    Thank you,
    Steve

OK, so the offending application is a screen capture
application of some type and the desire is to be
be able to do a 24 bit screen capture of an 8 bit
root window and a mix of 8 and 24 bit application
windows?  If so, I'd agree with your customer that
it is an X programming question.

Since it's a straightforward X screen capture
question, you might try a conference where more
X gurus hang out (Motif, CDE, Unix, ...).

Tom