Attached Link: http://www.xfx3d.net/headers.shtml

After a great deal of hacking away at them, I now have the Poser RSR Thumbnail format pegged down. It's a defiled Macintosh QuickDraw PICT2. The QuickDraw PICT2 format (usually just called PICT) is a format developed back in the late 80s as an extension to the PICT1 format, the original Macintosh native image file format. Almost all paint programs can open a PICT, but have fun trying to open a Poser RSR thumbnail. The reason behind it is this: A PICT file has a specific header on it, which contains meta-information about the PICT. This meta-information is primarily important because, from what I understand, it contains the specs on the size of the PICT image in question (as well as some standard information, like 'This is a PICT2 32 bit RGB image' and stuff. Well, thing is, in Poser, none of that meta-information is necessary, at all at all. Why? Because in Poser it can all be assumed. A Poser RSR thumbnail is supposed to be 91x91px RGB PICT2, no questions asked. Thus this all can be assumed by the application and the reast of the file can be read WITHOUT the PICT header. As a result, instead of the PICT header, it has some other stuff in there -- not sure what all it is, but I don't really need to know from what I can tell. If it's the same meta-information in a different format, it makes no difference to me because that information isn't supposed to change. 91x91px, RGB PICT2. Viola. Well, this header information is conveniently seperated from the rest of the binary information by that wonderful character we like to call a linefeed (n to programmers). The result? Well, if we take any other 91x91px PICT image and steal that top line, then we open a Poser RSR thumbnail (not a geometry RSR, a library icon one), we can whack off that first line, replace it with the one we swiped form the PICT image, and viola, we gots outselves a real genuine PICT. This PICT can be opened in Photoshop, PSP, and so on. Further, it can be converted to other file formats with all those nifty converters out there. And once I code a web application verison of this... I no longer have a reason ever again to bother with opening up p3do explorer, since I never used it for ANYTHING else. You can find the header files, isolated out in teensy binary files all by themselves, [here](http://www.xfx3d.net/headers.shtml)

You can use my Png2Rsr converter. In the rsr format was added another header to the pict image and a small epilogue.

Sounds groovy,Dodger.

Yes, kawecki, but that's not the point. There are plenty of MAT pose editors out there, too, but if I did a mini-tutorial on how to create MAT poses in a text editor, or on how to build a PHI file, I would hope someone wouldn't dismiss it with 'You can use MAT Pose Edit' or 'You can jusr use PHIBuilder'. And actually, I can't. Not for my purposes, which are to be able to support thumbnail RSRs as an imge format on xfx3d.net, which is on Linux and in a scripted environment.

Message edited on: 11/13/2005 22:06

In Mac OS, prior to the use of pngs, I believe that Martin C.'s MacConverter stripped out the data fork (everything but the first and last line) from the rsr file and added it to the PICT resource of the cr2 file. But now that they use pngs, there isn't any reason to deal with rsr thumbnail files, at least on the Mac side. With the exception of Poser 3 and 4, I guess, if that's the idea here.

Yup. Of course, on OSX if you want to do it now, it's easier... you just move things into the right directory mostly, since the resource fork is a directory next to the data fork directory in a 'bundle' format, seeing as OSX is sort of BSD with a different window manager.

My Cinema 4D plugin handles Poser RSR files on Windows as well as the MacOS Resource on MacOS. Yes, there's a PICT chunk. But a Mac Resource can contain almost any data. Do a search at Google for "Mac Resource File Format". The link to 'developer.apple.com' is the one to go to. One downside of this is that there is a tie between the RSR PICT file and QuickTime. Since there is currently no 64-bit version of QuickTime for Windows XP x64, Cinema 4D doesn't have the proper libraries (or whatever) to display them!

mateos_sancarlos, have you looked at your more recent Daz3D product installs lately! They no longer include PNG thumbs, only RSRs! Of course, these are automagically converted to PNG thumbs when you go the library folder in Poser 5/6.

Attached Link: http://www.daz3d.com/support/tutorial/printable.php?id=706

This is a nifty Free Stuff item, thats been using that .PICT format for years. .PICT(91x91 pixels) is all you need, it then converts whatever you have saved on your .PICT file to a .rsr in a second! I found it super becasue I could start using very large renders/composites as .RSRs by saving .PICTs right from Photoshop! I do'nt see a link right to this utilities download, but here is atutorial at DAZ. If you need a copy of the program I can look harder, or just e-mail you a copy of mine! = )

"Of course, these are automagically converted to PNG thumbs when you go the library folder in Poser 5/6" Actually, not quite. but close in an analogous sort of way. P5 and P6 still contain strings indicating they have been compiled with PICT-reading and storing headers. In other words, the binary reveals that the sourcecode used to compile P5 and P6 was written to be able to not only read, but hold a PICT in memory. I don't see any analogous code indicating a data structure for PNG metadata being stored in memory, though there's some stuff that looks like something to convert a PNG to PICT. This indicates that, in actuality, PNG images are automagically converted to PICTs in memory. This makes sense, of course, because it would be easier to add PNG functionaity by reading-and-translating PNGs than the reverse, since PICT support was already in the program (and, prior to the PC port of Poser, built into the Macintosh System APIs). We already know that the only time Poser has been torn down and rebuilt from the ground up completely clean was called DAZ Studio, after all. Additionally, from what I can tell, the popular theory that PPP and later 'use' greyscale bumpmaps is an illusion, too. It does, in fact, appear that Poser ProPack, P5, and P6 all actually read the greyscale bumpmap and convert it to a BUM. The difference is, of course, that PPP, P5 and P6 take the military approach. Don't ask, don't tell. And additionally, don't save -- they store the BUM data in memory only and discard it when the program exits rather than writing a huge BMP-with-a-different-name.

Illuminating and logically reasonable. :) Yes, I noticed that, for instance, BUMs are not converted to BMP greyscale maps in file format, but only in memory for PPP/P5/P6. It would have been nice had they gone that extra step to allow the final conversion of BUM normal maps to BMP greyscale maps as files, huge or not! ;)

I haven't done this, but there's an easy way to verify what the case is... If PNGs are just being displayed according to a standard PNG API like libpng or a closed-source equivalent, they are capable of more tricks than a PICT. I believe a PICT even has an animation capability (albeit rarely used). Try one and see what happens. If it shows up as intended, moves, whatever, then it's just displaying the PNG. If not, it's either translating (most likely) or possibly modifying and flattening on the fly (which would be a possibility, but pointless)

Attached Link: http://www.sensoft.com

> p3do explorer, since I never used it for ANYTHING else.

Note that this remark, only because I refused to give that guy any information on the RSR file format.
Probably that some people think they have some rights on the time I spent on that format, but I don't think so.

This is all I had to say, I just wanted to make clear the true nature of that thread.
Yarp

btw P3dO 1.7.8 beta 2 is available on my website ;)

Message edited on: 11/14/2005 01:52

Message edited on: 11/14/2005 01:54

"BUMs are not converted to BMP greyscale maps in file format, but only in memory" The process to convert to BUM is irreversible (there are tricks to get close, but never quite exactly all the way back -- the result will always differ at least slightly). THus BUM greenscale data is used in memory, and the greyscale file only lives in memory for as long as it takes to convert to BUM greenscale. From what I can tell, the greenscale data is used directly in the rendering, with the degree of green-red determining the variant to the percieved normal of the pixel, and thus the colour shift based on the illumination angle.

"Probably that some people think they have some rights on the time I spent on that format, but I don't think so" Scuse me? I ASKED. That's all. Had you said something like, 'Here's how to do it, but don't tell anyone!' guess what -- I wouldn't have ever posted any of this because it would be based on things I learned in confidence. Instead I worked it out on my own and, since I was frustrated with the complete lack of information on this subject on the web, I decided that the next guy or lady who finds him or herself trying to figure out how to read an RSR file shouldn't have to encounter this complete lack of information being available. I don't give a hoot what rights anyone has to the 'time you spent on that format' (BTW, Yarp, Curious Labs invented that 'format,' not you, just to clarify that). I do think EVERYONE has a right to the three hours I spent figuring out that format. If it was such a trade secret, Yarp, it's not anymore. And yes, the true nature of this thread is exactly what you said: Exposition (as the title of the thread should indicate) of the RSR file format so it is no longer a secret known by a few and helf closely to the chest. It's now part of the public record. Anyone who can write an image converter of any sort can now write an RSR converter. EFF would love me right now.

bad Dodger! dont you know its Against the Rules to talk about RSRs in public? ....and thanks btw .. I keep getting bloody annoying error messages in french from p3do .. this will sve me some cussing :)

BTW for the record, even if I'd never asked I would have posted this for people to know, because I was frustrated by the lack of information on this subject. Ironically, the only way I wouldn't have posted it is of Yarp or someone had told me and said 'hey, I want to keep this secret, so if I tell you you have to keep it to yourself.' (at which point I would have).

Seeing as I did work this out on my own, also, I plan to make a utility on XFX3d to build a web based converter -- which will convert from a shitload of image formats, allow you to upload an alpha mask image in case the type of file you upload doesn't have alpha channels (JPEG for instance), and not give a damn about how wide the file is (by converting it to 91x91 for you). Any error messages will be in English, 'cause it's what I speak.

The process to convert to BUM is irreversible (there are tricks to get close, but never quite exactly all the way back -- the result will always differ at least slightly). Most definitely! Yes, it requires a Calculus integration to convert one to the other. Anthony Appleyard, who seems to be well grounded in the mathematics, provided crucial means to do just this for interPoser. As you say, though, it is never quite exact. Or, more correctly, the more 'exact', the longer the conversion! THus BUM greenscale data is used in memory, and the greyscale file only lives in memory for as long as it takes to convert to BUM greenscale. From what I can tell, the greenscale data is used directly in the rendering, with the degree of green-red determining the variant to the percieved normal of the pixel, and thus the colour shift based on the illumination angle. There seem to be camps that favor one over the other. I can see the merits of normal maps over bump maps (and vice versa). With the advent of sub-polygon displacement, I don't see the advantages of either except in rare cases where speed over detail is important (e.g.: game engines). Interesting to note is that the latest version of Cinema 4D seems to have added normal maps to its repetoire. A little late, but it may prove useful for interPoser Pro at some stage. :)

I'm glad that you made mention of this. Yes, Poser's Mac heritage is alive and well in the RSR file format. Be careful about extracting it. If you do it manually (as I've done), there are some tricky issues to deal with. As usual, I'm not any sort of bigot or secretist who would curtail the advancement of knowledge if it provides better toys, er, utilities! ;0)

I don't wanted to reply that thread any more but I won't let you disguiss the truth. > Had you said something like, 'Here's how to do it, but don't tell anyone!' guess what I said : "Seno Software is a commercial company and I don't give any information on P3dO internals. For such information please see CL." btw The "secretist" provided a free picture converter with his not so secret secret, since you found it so quickly. FREE do you understand ? Next time you e-mail me why don't you ask the P3dO source code ? I think I should think twice before saying no again.

Of course there is more to P3DO than just the RSR feature, but I would like to point out that if you wish to batch convert across multiple folders then you have to buy the the Pro version; the free version only does it folder by folder. So I guess a utility just for rsr conversion would have a big following.

I'm afraid I don't understand what the argument is about. Person A asked Person B, who has already figured out the format, if they can tell them about the format of a graphic. Person B declines. Person A then figures it out on their own, and takes that knowledge and shares it. What's the issue? I'm completely serious in this, I honestly don't understand why anyone is "attacking" anyone else with regard to the format of an .rsr. I use P3d0 for more than just converting .png to .rsr, and probably other people do as well, but I'm positive that some people really do only use it for that purpose, so what's the beef? I guess I just don't get it. shrug bonni

Attached Link: http://www.renderosity.com/messages.ez?ForumID=12356&Form.ShowMessage=2470411

Just so you know, dodger... A little smear campaign is in effect

elizabyte, the fact is not person A makes a new software. I've nothing against this. The fact is that person A because I refused to help him, is attacking P3dO - for this sole purpose. This is not an honest attack or critisim, so I can stay sitting and let him do. There are software doing more or less what P3dO does, no problem with this. Hatred or revenge is the subject.

is attacking P3dO I don't understand where he's attacking your software... ? Or are you saying that he's only revealing that an .rsr is a corrupt PICT2 in order to extract some sort of revenge... ? I'm just genuinely perplexed, and NOT trying to pick a fight. bonni

Well the technological stuff is interesting, and I appreciate the shared info, and look forward to more web-based apps that a Mac user, like myself, can play with. ^^

Well, this approach may work for most RSRs, but not for all. And i don't know if i should be too happy about a tool that'll generate RSRs with incorrect content...

I think it's time for everyone to just take a deep breathe and relax. Let's try to not let this get out of hand :-) Thanks Angel1

The RSR format isn't that difficult to figure out enough to be able to convert to PNG.
The problem is that the alpha-less 24 bit PICTs need different handling than what's in the available code.

http://www.renderosity.com/messages.ez?Form.ShowMessage=2460189
http://www.renderosity.com/messages.ez?Form.ShowMessage=2403024

I have the RSR format and it was not difficult to discover it. The only use that I had for a converter is to convert Poser5 png thumbs or to create thumbs with images that use transparencies. The program that used before was a small Poser utility that converted pct to rsr. P3do that a lot of things that I don't need and have my own viewers, and the very old version that I have failed to convert properly many thumbs. One day I decided to do a simple programs, easy to use and with batch conversion, so I needed to know the rsr format, I was not able to foumd anywhere this format so I had the following alternatives: 1) Email Curious Lab, probably they will not answer of give me the format. 2) Try to discover who made the pct to rsr converter and try to contact him. 3) Email Yarp, he use it in a comercial program, probably will not give me, but I also could try to negociate some exchange. 4) Discover by myself, and this what I did and is was easy to do it. - It was an old format, so the data must be in raw format or a simple compression algorithm. - The key was the pct to rsr convertor, why this guy used a strange pct format as input, he must have done something very simple to convert. There was a big probability that rsr was a pct renamed. I looked the hex code of pct and the converted rsr and discovered that in spite not were identical both data was almost equal with exception of the headers. I downloaded pict2 format specifications and so discovered the rsr header, the data is the same as pict with RLE encoding. To do rsr to pct or pct to rsr converter is something very easy, but I don't want pct, I want png! Png format is known, documented and pnglib is open source, so a png to rsr would be an easy task, it wasn't! I spend one day to convert bmp to rsr and more than a weak trying to do a png reader, png got me crazy! Png is well documented, but there were features that were nothing clear in the documentation and pnglib structure that is a general structure was not something that fitted my needs. The problem was not rsr, the problem was png! Anyway, it's done.

"The problem is that the alpha-less 24 bit PICTs need different handling than what's in the available code." The general structure for a convertor 1) Convert the source image 24/32 bit image to an internal memory structure. 2) Convert the internal memory structure to a 24/32 bit output image. In my convertor I use as the internal memory structure a 32 bit RGBA image, also use this representation for diplaying the preview image.

I for one am greatful for this information. It's something I've wanted for some time. Yarp, you have produced a great product and have been extremely generous in making such a functional version available for free. I do think you are overreacting here. I don't see how Dodger is putting P3DO down by saying that the conversion function is all he uses it for. As I said, it's a great program but truthfully, almost the only time I use it is for the conversion. That's just the way I use Poser. I wrote my own application to deal with my zip archives and being able to support rsr thumbs now will be great. Honestly, if Dodger is dissing you, I think it's so subtle that you are the only one who sees it so I wouldn't worry too much.

I once went to the fights and a hockey game broke out.
8 )
Tom

Message edited on: 11/14/2005 19:21

Don't mention hockey. I'm only here because the Avalanche is playing sooo "well". ;)

Actually, Yarp, can I ask two questions and get honest answers to them? 1) Do you want people to know how the RSR file format works, or would you prefer if it had been kept a secret? 2a) If you don't mind people knowing how RSRs work:     Why refuse to tell and act like it's some big trade secret? || 2b) If you do not want people to know how RSRs work:     Why not? What are your reasons for wanting it kept secret?

To the general public who knows of Dodger, whether you like him or not: Do you think that if Dodger had not asked Yarp how RSRs work, and had only figured it out on his own without asking someone who obviously knew first, that he would have kept this information secret, based on his history of sharing information?

I am not defending nobody. Why this has to turn into a personal attack against Yarp? I also know the RSR format and nobody has asked me for it and even nobody knows if I'll give it or not.

Ladies and Gentlemen of the Moderators and Admins, allow us to state herein formally that we, the constituents of XFX3d (there are more of us than merely Dodger, and he is only one representative of the organization, among four), believe that Yarp has presented a personal attack and launched a seperate smear campaign because the ability to freely use tools people already have available reduces the usefulness of his P3DO Fxplorer program, and thus reduces the likelihood that people will download it, and, further, that the free program is used as a promotion for the paid version of the program which includes additional functionality, and that his claims that he is being attacked in some way by the sharing of information is a ploy to attempt to divert attention away with this information being shared, at the very least. Thus it is our considered opinion that his smear campaign in another thread and his disparagement of the free sharing of information, something that is generally assumed to be commonplace in the market, is motivated by the potential for personal gain and the potential threat to that that the breaking of a perceived monopoly on the ability to perform such conversions represents. Further, let it be stated that while xfx3d may, in fact, gain from this information in some way at some point in the future (though we do not yet know how), it is generally considered not only acceptable, but laudable to give aaway information freely in hope of potential future gain (as represented by the existence of websites such as Google, Yahoo!, industries such as Television, DAZ3d's free 'tellware' sharing of the DAZ Studio program and, in fact, Yarp's own free version of P3DO Fxplorer, and that all such gifts to the community, regardless of motive, should be applauded. However, conversely, launching an attack and smear campaign against someone's person for such free sharing of information is not something that we at XFX3d condone or accept as civilised behavior. And finally, and further for the record, let it be stated formally that while Dodger requested the information, he was not, in fact, the one who actually mailed Yarp to ask (though he was the one who replied pointing out to Yarp that since he had figured it out on his own --he does all of our development-- it was going to become public knowledge, and that his apparent goal of keeping it a secret backfired).

"Why this has to turn into a personal attack against Yarp?" It hasn't. It has, rather, turned into a defence against a personal attack FROM Yarp, who apparently protested our public sharing of this information, despite the fact that we did not obtain this information from Yarp.

Back to the technical discussion, here's Dodger back: I've noted that there is a difference between the RSR footers generated by P3D0 Explorer, Poser, and PICT2RSR. The 'footer' is the last line, plus the last 37 characters and newline character seperating the two. The Newline is consistently the same, of course, as is the last line, which reads (with control characters transliterated): ^@~@^@^@^@^@^@^@^@^@^@^@^Gpreview However, the last 37 bytes of the second to last line in the files differ as follows:

^@^@^A^@^@^@!^@^@ ^@^@^@:^@^@^@^@^@^@^@^@^@^^@2^@^@PICT^@^@^@ = P3DO
^@^@^A^@^@^@&^V^@^@%^V^@^@^@:^@^@^@^@^@^@^@^@^@^^@2^@^@PICT^@^@^@ = PICT2RSR
^@^@^A^@^@^@#^@^@"^@^@^@:^@^@^@^@^@^@^@^@^@^^@2^@^@PICT^@^@^@ = Poser Generated RSR

However, they appear to be the same reuslts from each different method of generating an RSR. I.e., from my tests, the results are the same for each program as listed above. While I doubt I'll get any sort of answer from Yarp, since you also know the format, kawecki, would you care to share your thoughts on why this is, and what the significance of those differences is?

It should be noted that, from what I can tell, it's bytes -30 to -23 (- sign indicates counting backwards form the newline on the end of the file)

Is this some sort of identifier or something?

The hex looks like this: (differing code in red)

<br></br>000023A0   A6 7F 00 FF  00 00 01 00  00 00   ..........  00 00 00 00  00 00 00 00  00 1C 00 32  ...........2<br></br>000023C0   00 00 50 49  43 54 00 00  00 0A 00 80  00 00 00 00  ..PICT..........<br></br>000023D0   00 00 00 00  00 00 07 70  72 65 76 69  65 77        .......preview<br></br>

Message edited on: 11/14/2005 21:24

Message edited on: 11/14/2005 21:24

For a p3do converted file, the red hex string above would be: 26 16 00 00 25 16 00 00 00 3A For a PICT2RSR converted one, it reads: 21 AC 00 00 20 AC 00 00 00 3A

It should be noted that this can be further isolated to some extent, as the two null byte string and the three null byte string are both in the same place. Thus the difference seems to only be these two triplets:

23 A4 vs 26 16 vs 21 AC
and
22 A4 vs 25 16 vs 20 AC

In all of these files, the two segments to not match but are inversely consecutive on the first byte and a match on the second (though the three do not match one another, again). Thus we have 23,A4;22,A4 and 26,16;25,16 and 21,AC;20AC, respectively.

Message edited on: 11/14/2005 21:38

I think it just reflects society today, where big companies want to keep everything a secret so independents can't produce anything to compete with their products. Patents and copyright have run rampant. Free software forever!

PICT data ends with 0xFF
Next comes the epilogue
size = size of whole previous block
headersize = 0x0104 (260 bytes)

DWORD headersize - 4
DWORD size
DWORD size - headersize + 4;
DWORD 0x003A // unknown
DWORD 0 // unknown
DWORD 0 // unknown
WORD 0x1C // unknown
WORD 0x32 // unknown
WORD 0 // unknown
BYTE "PICT"
BYTE 0,0,0,0x0A // unknown
BYTE 0,0x80,0,0 // unknown
BYTE 0,0,0,0 // unknown
BYTE 0,0,0,0 // unknown
BYTE 0x07 // sizeof("preview")
BYTE "preview"

DWORD and WORD are in Motorola format and not in Intel Format (most significative byte first)

unknown looks as always is the same in all rsrs

Message edited on: 11/14/2005 22:05

I just discovered the meaning of 0x003A (58) is the size of the epilogue!!!!!!

Cool!

UPDATE DWORD headersize - 4 DWORD size DWORD size - headersize + 4; DWORD 0x003A // epilogue size DWORD 0 // unknown DWORD 0 // unknown WORD 0x1C // unknown WORD 0x32 // unknown WORD 0 // unknown BYTE "PICT" // "ACTR" for geometry files BYTE 0,0,0,0x0A // unknown BYTE 0,0x80,0,0 // unknown (0,0x0D,0,0 for geometry) BYTE 0,0,0,0 // unknown BYTE 0,0,0,0 // unknown BYTE 0x07 // sizeof("preview") BYTE "preview" // (geometry: file location of obj)

Just curious why you have ' BYTE 0,0,0,0x0A // unknown' marked as a BYE instead of a DWORD, seeing as it's unknown. Also, I was noticing the 00 80 00 00 one, if it was split into two seperate words, would be (128, NULL) and while I don't know what that would fit in as, might mean something (certainly more likely to mean something than the alternative if treated as a DWORD, of 8388608, anyway)

Here's the Perl pack() template for this bitstream: NNNNx8nnx2A4x2nnx10cA7