perhaps its the way it mixes them? cuz the Red and Grn are writen, they look fine like poser window then its just the Out file that isnt right maybe a typo in read/write code?

Hey ockham, would you please send the 'c' source to me again? or include it in the zip? I was wondering if I would see anything. I am off to test version 6 myself.

Attached Link: http://ockhamsbungalow.com/PPP/Anaglyph7.zip

argh.. I looked everywhere and I can't find any 3d red-blue (or is it red-green) glasses.. I found some sheets of colored plastic from an ancient project of mine and I might be able to construct some, but I am not sure I have the colors right. The red plastic sheet I have filters OK (I can't see the ghost red) but the blue / green does not (I can still see both ghost images). I am not getting (much) 3D effect. Which eye should be RED and which should be BLUE? The AnaglyphRender.py was set to display not render (I had to uncomment it). It does a double render each time I clicked the adjust angle. Hmm..

The latest zip does include the C source, incidentally. On my computer, adding the #pragma pack(1) to the rgb struct seemed to make a difference. ????

set my poser window to 400x and 500x and still same result i wouldnt think that it as anything to do with my video drivers would it? doesnt seem to matter my poser window size and yes i installed them right :( underdog, theres places on net you can get 3d glasses free well costs you 2 stamps (37 cent per in US) you can get a pair sent back to ya :) just look on net you'll want red/cyan glasses, cyan is blue+green in 1 its like a light blue, tht shows anaglyphs (as long as they were created for it) to show in much better color and red goes over left eye also another addition if you feel like it (if script works for others may as well continue to make it better, or wait till works for me lol) but set radio buttons in it (select one and it unselects rest) and give following 1) red/blue 2) red/green 3) red/cyan (blue+green) there is also black/white anaglyphs but forgot how the color channels are used for making them, they still have red/cyan ghosts, but main part shows b/w, but i guess skip that till found how to make just an idea for sometime =S

Unless Underdog can find the problem in my mixing code, I'll just have to bite the bullet and use a much more complicated form of mixing. (Using the BitBlt actions within Windows.) Judging from experience with similar tasks, it will run slower than the current method, but it will also less sensitive to file-format.

I haven't opened up the source yet. You will need to give me some time on that. I don't have a compiler installed and haven't compiled in 'C' on a windows box in about 5 or 10 years (literally).. I have on unix but that doesn't count :) Can I download a compiler somewhere or do I have to use the microsoft visual c (or whatever they are calling it).. assuming I wanted to compile this. Let me see if I can glean anything else from the code. I hate to resort to bit-blit just yet.. But I think that having a 3d mode in Poser output would be way cool. I have some shutter glasses (... WIRELESS! now that's an improvement over the Amiga days!) that I can dig up.. Anxcon, thanks for the red-blue glasses tips. I will perservere.. I hate waiting for snail mail. I wish I could buy them at a grocery store. but sadly, most folks think they are not a commodity.

The source code looks fine to me. I am focusing on the Mix function for two reasons. First, the rest is over my head. Second, Mix is either generating a good BMP file for "Out.BMP" or it is not. The display on the Tk dialog box is secondary at the moment. If the large image looks ok, then we worry about the Tk dialog. Make sense? So: Anxcon, are the BMP files jacked up? Would you please send one to me at my underdog account at fantasy3d.com? Please send me a Red.bmp, Grn.bmp and Out.BMP so that I can see how they are being incorrectly combined. Yes, I realize you have already done this for Ockham, but as Eric Raymond (?) says, bugs don't last long with 1000's of eyes are looking at them (or pairs of eyes in this case). ===Underdog===

comic stores also usually have them and spy kids 3d left movies stores with a ton you could try there as well

actually, it was spy-kids 3d that forced me to make a couple pair the last time! we rented the 2 disk dvd from blockbuster only to discover that there were no glasses in the case. When I called the local blockbuster, they said, yeah, none came with it! I was not amused and pretty suspicious, but the only choice was to return the dvd or... make some glasses. So I did plan 'B' and it worked out fine. But now they are gone, alas..

sent pics to underdog

Hi Ockham and Anx Con..

I got the pics. Not much to report. The merged pic is clearly corrupted, but in an odd way. I zoomed in on the Aux Camera / Main Camera overlay and that shows pixel variations in places where we should see identical colors (in other words, where one set of letters is printed on a solid color without overlap from the other set of letters), but instead the pixels seem to alternate colors in a pattern.

Researching the BMP file format on the web, it looks to me like the file header on an uncompressed BMP file should be 54 bytes, not 36 bytes. Maybe this is corrupting things. Ockham, tell me if you agree after checking this link?

http://www.daubnet.com/formats/BMP.html

I assume the layout is valid.. Doesn't it seem to indicate that the raster data starts after the 54th byte?

<br></br>Header 14 bytes Windows Structure: BITMAPFILEHEADER <br></br><br></br>  Signature       2 bytes 'BM' <br></br>  FileSize        4 bytes File size in bytes <br></br>  reserved        4 bytes unused (=0) <br></br>  DataOffset      4 bytes File offset to Raster Data <br></br><br></br>InfoHeader 40 bytes Windows Structure: BITMAPINFOHEADER <br></br><br></br>  Size            4 bytes Size of InfoHeader =40  <br></br>  Width           4 bytes Bitmap Width <br></br>  Height          4 bytes Bitmap Height <br></br>  Planes          2 bytes Number of Planes (=1) <br></br>  BitCount        2 bytes Bits per Pixel   <br></br><br></br>     1 = monochrome palette. NumColors = 1   <br></br>     4 = 4bit palletized. NumColors = 16   <br></br>     8 = 8bit palletized. NumColors = 256  <br></br>    16 = 16bit RGB. NumColors = 65536 (?)  <br></br>    24 = 24bit RGB. NumColors = 16M <br></br><br></br>  Compression     4 bytes Type of Compression   <br></br><br></br>    0 = BI_RGB   no compression   <br></br>    1 = BI_RLE8 8bit RLE encoding   <br></br>    2 = BI_RLE4 4bit RLE encoding <br></br><br></br>  ImageSize       4 bytes (compressed) Size of Image  <br></br>    It is valid to set this =0 if Compression = 0 <br></br>  XpixelsPerM     4 bytes horizontal resolution: Pixels/meter <br></br>  YpixelsPerM     4 bytes vertical resolution: Pixels/meter <br></br>  ColorsUsed      4 bytes Number of actually used colors <br></br>  ColorsImportant 4 bytes Number of important colors 0 = all

===Underdog===

Ah Hah! I just realized that 36 hex == 54 decimal.. coincidence? Expiring minds want to know!

I also read this (sorry for the short, scattershot posts)..

Raster Data encoding for 24bit / truecolor images<br></br>BitCount = 24 Compression = 0<br></br><br></br>Every 4bytes / 32bit holds 1 pixel. The first holds its<br></br>red, the second its green, and the third its blue<br></br>intensity. The fourth byte is reserved and should be zero.<br></br>There are no color table entries. The pixels are no color<br></br>table pointers. No zero padding necessary.

If I understood the code correctly (notice that "if" at the beginning of this line), I think you are pulling 3 bytes at a time for each pixel (r,g,b), and not skipping the 4th (reserved) byte... If so, doesn't this mean that something's got to go wrong?

The problem I am having with this is that it would seem that something would go wrong RIGHT AWAY and stay wrong!! I would think that the picture would end up being pretty strange looking. So, I must be missing something with this one, but I thought I should mention it.

Attached Link: http://ockhamsbungalow.com/PPP/Anaglyph8.zip

There are 10 types of people in the world. Those that understand binary and those that don't. :-D

I gotta get to bed soon, but I will download it and give it a try first.

Culater. Oh and did you see that part about using all 32bits for each pixel rather than 24bits? are you reading in 3 bytes or 4 each pixel?

Message edited on: 02/06/2005 23:40

As for the four bytes versus three bytes, that is a valid difference, which I did try both ways at an earlier point in writing this. But it's clear from the above view that Poser uses straight 3-byte coding in the BMPs it writes. I was actually writing this mix process for an all-in-Poser camera cutter and fader script, so I just used it here because it was similar. The camera fader was in fact suffering from a similar mysterious lack of sync, which can now be solved thanks to your catch!

I did a bit of investigation, and I agree that 3 bytes per pixel seems to be the rule, not 4. I did this using photoshop, not poser, but even there an uncompressed 24 bit image seems to be in a different format than what I find documented on the web.

The screenshot is a hex dump of a 10x1 pixel BMP with alternating white and black pixels. This BMP shows me that we have FF FF FF 00 00 00 FF FF FF 00 00 00 repeating patterns.. Hmmm..

There's one (small) thing that may be wrong..

This is a super zoomed in screenshot of the upper left corner of the combined image. I wonder if the colors are correct. I put this on a black background (pixels = 0x00 0x00 0x00). The camera names are solid white (0xFF 0xFF 0xFF).

In a perfect world (which I realize red-blue filters ain't) we would see a white Main Camera through one eye and a white Aux Camera through the other eye. They would both appear "white". Now I know they can't be white, but is something close to that happening? I am without red-blue glasses, as I have droned on endlessly about already..

hmm......... k 1st, i deleted and reinstalled the scripts i know i got correct files in tried preview script, and still has same problem (as if no change) tried the render script (thought you added part so doesnt render until "show" is clicked? its instant render still) forgot to mention says a window with the msg, not found E:Profile FilesPoser 5RuntimePythonposerScriptsAnaglyphAnaglyphRender.py but still triggers the rendering and makes a pic like preview and still same line problem should i just kill my comp? lol

Yes, I've been wondering about the colors as well. The problem is even worse in the cam-fade mixing. I haven't found any good documentation on the best method for a "convincing" colormix at the pixel level. This may be more of a perceptual thing than a strictly programming/math thing. Would the eye do better with alternating scan lines instead of OR'ing each pixel? Guess we'll have to wait for Anxcon to apply the goggles.... Think I'll order a pair just to join the fun, though.

It's bedtime for me. Maybe you should delete everything related to this, including folders, and re-install from latest link? After so many revisions, old versions can get tucked into places where you may not realize.

yes, I agree, and I am past my bedtime too. anxcon, be sure you have REMOVED these files and then reinstall: ...RuntimePythonDLLs_Anaglyphmodule15.pyd ...RuntimePythonDLLs_Anaglyphmodule22.pyd And you are right about the code reverting back on the show button, etc. We can tweak how the buttons work after we get the images right. Those two pyd files are were the action is. Be sure they are dead. You might make sure Poser is closed too, in case it keeps them in memory or something. Hell, even a reboot isn't out of the question, considering it's windows. One concern I have is that I am doing all of this on P4 and so is Ockham, I think. But that really should not matter in this case. I think. :)

To remove the startup render, just find line 93 in AnaglyphRender.py and delete it. Line looks like this: self.Action() # Show once And yes, I'm mostly using P4 because P5 is just so slow, but I'm testing some steps in P5.

ill format my drive and test a new

as for the color mixing underdog shows
thats a green+red=yellow-aux/blue-main
my guess is just out of phase selection of colors
try switching the points the script uses as blue and red
should show as red/cyan(light blue) ghosts
whereas underdog shows blue/yellow
i dont need glasses for that :)
i dont get to goto bed for another 3 hours ): PST time sucks ill finish this before i go and leave the results tho :)

Message edited on: 02/07/2005 00:56

Ockham: I don't think that removing the Action method in the main program will work. I am pretty sure I tried that, but there are side effects like you need the camera parameters that Action uses or something.. IIRC, I had to create a separate subroutine to initialize the camera.. It also needed to be done for the left and right buttons... But maybe the code has changed or I missed something.

(and btw, I thought you were going to bed?)

No, no, don't format your drive! Hope you're just kidding about that. Just be sure those PYD files are fully gone, then re-install.

Re the Action: Ok, that makes sense. I'll handle that in the morning when I'm (comparatively) fresh.

This script replaces AnaglyphRender.py and I will post a similar one for AnaglyphPreview.py in just a sec..

Then I swear-ta-god I am going to bed. And btw, ockham, if you disagree with any of these tweaks, you won't hurt my feelings by telling me.

the format thing yes accually was serious =P i have 4 drives, system/archive/programs/programs last 2 are basicly same, been testing on both have 2 poser installed incase 1 drive dies but anyways archive drive has backup of everything basicly i can format and copy back in 10 minutes max which i just did to 1 drive lol no biggy to me have that setup cuz popups on websites kill me :S (dont comment) anyways back to script started clean and same problem but i looked at picture up close tryin to help more Out.bmp is showing like line 1 red line 2 green line 3 blue line 4 red not all like that, its just the "ghost" parts mainly where ghost shouldve been red/cyan also i running v5.0.0.229 for poser 5 perhaps im out of date or something? will look for updates cant think of much else, also tired lol

scratch the version update for me, did nothing this thread is getting long ^_^

Ockham, I recommend you rename the DLLs just to be sure anxcon isn't somehow picking up old ones. Yeah I know it doesn't sound like it, but that drives a stake through the heart of that issue and we don't have to worry about it anymore.

I haven't tested yet on P5. I have a day-job so I won't do that until about 6 or later CST. But I can't understand why a P5 24-bit BMP image is different from a P4 24-bit BMP image... Hmmmm...

Anxcon: Are you saying that you COMPLETELY REMOVED all instances of your Poser 5 installation?? Wow.

Maybe we should switch to a new thread?

Message edited on: 02/07/2005 07:09

Anxcon: Your Poser 5 isn't the latest. I have 5.0.4.321 . Earlier versions of P5 did have big problems in rendering, which included some scan-line oddities IIRC. That may not be the problem here, but you should certainly update for general purposes anyway!

And I'll start a new thread. This one is almost as long as the 3-year-old Wish List thread!