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)

I'm the asshole. You wanna be a shit? You gotta go through ME.

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

Stupidity also evolves!

Sounds groovy,Dodger.

Coppula eam se non posit acceptera jocularum.

My Store

My Gallery

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

I'm the asshole. You wanna be a shit? You gotta go through ME.

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.

I'm the asshole. You wanna be a shit? You gotta go through ME.

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!

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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.

I'm the asshole. You wanna be a shit? You gotta go through ME.

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! ;)

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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)

I'm the asshole. You wanna be a shit? You gotta go through ME.

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

Yarp - author of P3DO Organizer for Poser

"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.

I'm the asshole. You wanna be a shit? You gotta go through ME.

"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.

I'm the asshole. You wanna be a shit? You gotta go through ME.

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).

I'm the asshole. You wanna be a shit? You gotta go through ME.

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.

I'm the asshole. You wanna be a shit? You gotta go through ME.

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. :)

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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)

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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.

Yarp - author of P3DO Organizer for Poser

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

"When a man gives his opinion, he's a man. When a woman gives her opinion, she's a bitch." - Bette Davis

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.

Yarp - author of P3DO Organizer for Poser

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

"When a man gives his opinion, he's a man. When a woman gives her opinion, she's a bitch." - Bette Davis

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. ^^

Calypso Dreams... My Art- http://www.calypso-dreams.com

Renderosity Gallery

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

....Now Bring Me That Horizon....
Send IM | Gallery

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.

Stupidity also evolves!

"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.

Stupidity also evolves!

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.

"Democracy is a pathetic belief in the collective wisdom of individual ignorance." - H. L. Mencken

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

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

“The fact that no one understands you…Doesn’t make you an artist.”

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

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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?

I'm the asshole. You wanna be a shit? You gotta go through ME.

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'm the asshole. You wanna be a shit? You gotta go through ME.

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.

Stupidity also evolves!

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).

I'm the asshole. You wanna be a shit? You gotta go through ME.

"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.

I'm the asshole. You wanna be a shit? You gotta go through ME.

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?

I'm the asshole. You wanna be a shit? You gotta go through ME.

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

I'm the asshole. You wanna be a shit? You gotta go through ME.

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

I'm the asshole. You wanna be a shit? You gotta go through ME.

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'm the asshole. You wanna be a shit? You gotta go through ME.

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

Stupidity also evolves!

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

Stupidity also evolves!

Cool!

I'm the asshole. You wanna be a shit? You gotta go through ME.

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)

Stupidity also evolves!

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)

I'm the asshole. You wanna be a shit? You gotta go through ME.

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

I'm the asshole. You wanna be a shit? You gotta go through ME.

BTW to use that in perl, pass it the following values (assuming you have values for the strings): ($hsize-4, $size, $size - $hsize + 4, $fsize, 28, 50, 'PICT', 10, 128, 7, 'preview')

I'm the asshole. You wanna be a shit? You gotta go through ME.

I put the unknown as a sequence of BYTES because I don't know how are divided. Beware how you output the value of WORD and DWORD, in Mac it will work normally, but in PC you must create special routines: PutWord(a) = PutByte(HIGHBYTE(a)); PutByte(LOWBYTE(a)); PutDword(a) = PutWord(HIGHWORD(a)); PutWord(LOWWORD(a));

Stupidity also evolves!

Frankly I use the rsr convertor - I never had any luck with the p3do convertor and my rsr files.

3-D Arena | Instagram | Facebook

I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use.
-Galileo

"Beware how you output the value of WORD and DWORD, in Mac it will work normally, but in PC you must create special routines" Well, rather than using the local byte significance, my pack() template up there specifically uses N and n for DWORDs and WORDs, respectively (or, rather, in a more perlish sense, long and short integers). The N/n is a specific packing format. It's automatically big-endian, and always 32 or 16 bits exactly. This is in contract with i and I which are signed and unsigned integers respectively which are compiler-depentent in length and architecture dependent in byte order. s and S which are short integers following the same logic, l and L are similar, but always exactly 32 bits, still architecture dependent on byte order, and v and V are like the n and N sizes, but always little-endian. q and Q are quad (64 bit) values, but if your system doesn't support 64 bit integers or Perl wasn't compiled to support them, it fatals when it runs. As a result, only n, N, v and V of all of these are recommended for portability. For mnenonic, N stands for 'Network Order' (big endian, like a Motorola or Sun processor) and v stands for 'Vax Order' (little-endian, like a Vax or IA-32 based machine). So yeah, from C you would, but Perl handles the difference quite cleanly and even expects to deal with it. Big reason is that Perl has come installed standard on UNIX and Linux machines for a decade and is meant as a fast scripting language. Not building in portable-output options would make a lot of messes, especialy since the most popular *nixes are Linux (usually on x86 so little-endian), Solaris (big-endian), and the currently immensely popular FreeBSD (which may be either, as it works fine on a x86 box, but it's most popular distribution nowadays is named after assorted jungle cats, currently Tiger, and very much big-endian).

I'm the asshole. You wanna be a shit? You gotta go through ME.

I only use C and Assembler in parts where speed is important.

Stupidity also evolves!

I wrote a small Python script to convert RSRs to PNGs a while back, since I couldn't find any. So if anyone's interested ... martin

mkrueger: that's cool, does it run from within Poser? And do you have one to do the converse?

I'm the asshole. You wanna be a shit? You gotta go through ME.

mkrueger. Sound really cool ! And as XFX3d said, does it work from within Poser ?

Currently it's oneway from RSR to PNG and works in two steps: it first extracts the PICT from the RSR and then converts the PICT to PNG. The extraction should work in Poser since it is plain Python, but the PICT -> PNG conversion uses PythonMagick, a binding for the ImageMagick library. This could be replaced by a call to an external batch script (ImageMagick's convert or Irfanview for example). Or somebody knows another library to convert it in Python (I didn't find anything else) ? martin

Since it's calling ImageMagick, then it can convert back to RSR based on the info in this here thread.

I'm the asshole. You wanna be a shit? You gotta go through ME.

I tried this on three rsr files (converting to pict). I could only get it to work on one. Of course, I just a country database programmer so I may may be missing something here. Oddly, the two that didn't work were from my runtime and the one that did was straight from a zip archive. Is it possible that rsr's created from pngs using P3DO won't work using this method? Apologies if that's been covered and went over my head.

"Democracy is a pathetic belief in the collective wisdom of individual ignorance." - H. L. Mencken

XFX3d: I'm not sure what you mean. I used the Python binding for ImageMagick which is compiled against Python 2.4, so this doesn't work in Poser itself. As far as I know, there isn't a binary package of PythonMagick for Python 2.2. And for the return way, you get as far as a PICT file. BTW, I just finished coding the PICT to RSR part, which is a bit more tedious than to simply extract the PICT, since you have to build the whole RSR. I will try to compile the PythonMagick sources against python22.dll, but I wouldn't hold out much hope, I fear I will just stumble around not knowing what to do ;) martin

Kawecki: The third BYTE in there, which is unknown, I have a clue on. I don't know specifically why it's 128 for a thumbnail, but the 0x0D on a geometry RSR seems to fit perfectly with the following load line from most CR2s:

   geomHandlerGeom 13 hip  

So, I'd reckon there's a direct code reference therein. It might be possible to change it to 0E and then in a CR2 change the geomHandlerGeom lines to say geomHandlerGeom 14 hip and so on and have it load properly. Not that there'd be any point to doing so, but still.

I'm the asshole. You wanna be a shit? You gotta go through ME.

Oh, yeah, and the 0x0A after 'PICT' is the newline character ("n") that seperates the bit below form the above. It's probably used as a marker.

Message edited on: 11/16/2005 22:57

I'm the asshole. You wanna be a shit? You gotta go through ME.

Anyway the unknowns have no importance and are always the same, so is enough to copy them as it are.

Stupidity also evolves!

Important note: DWORD size - headersize + 4 That's actually (size - headersize) + 4 Without the parentheses, in normal operator precedence in most languages, it would be size - (headersize + 4). In other words, it's size - 256, not size - 264

I'm the asshole. You wanna be a shit? You gotta go through ME.

The following perl code will convert any image format supported by ImageMagick to an RSR. It will scale to 91px width. Really old versions of ImageMagick will cause it to scale like if you had 'constrain proportions' turned off in an image program, so make sure it's new (or add some code to calculate the height -- have fun, I've done that and it's annoying). New versions of ImageMagick scale it proportionally automatically unless forced otherwise, which is the behaviour one would want. You have to have Perl which you can get free from CPAN or, for Windows users, ActiveState Mac OSX users probably already have Perl installed. At least, as far as I know. If not, it's probably on your OSX CD, maybe under the BSD substytem stuff or something. You also have to have ImageMagick installed, as well as the PerlMagick (Image::Magick) libraries. Those can be found for free at The ImageMagick Site. This does support images taller than 91px, BTW. You may use and redistribute this code under the terms of the Perl Artistic Licence Use it like this (assuming you named it makeRSR.pl): perl makeRSR.pl image.ext > image.rsr

#!/usr/bin/perl
use strict;
use Image::Magick;

my $infile = shift;
die "Usage: $0 <infile>n" unless $infile;
die "File $infile does not existn" unless -e $infile;

my $image = Image::Magick->new;

my $ret = $image->Read($infile);
if ($ret) {
    die "ImageMagick Error: $retn";
}

if (scalar @{$image} > 1) {
    # Flatten layers and/or remove animation
    $image = $image->Flatten;
}

$ret = $image->Scale(width => 91);

unless ($image->Get('magick') eq 'PICT') {
    $image->Negate(channel => 'alpha');
}

$image->Set('magick' => 'PICT');

my $height = $image->Get('height');
my $width = 91;
my $data = $image->ImageToBlob;

my @data = split /n/, $data;
shift @data;
$data = join "n", @data;

my $size = length($data) + 304;
my $dpi = 72; # assume 72dpi of course

# Create the RSR header
my $header = pack 'NNNNx240Nnx4nnnCCCxCCNNx6nnx4nxa',
                  256, $size, $size - 256, 58, $size - 260, $size - 260,
                  $height, $width, 17, 2, 255, 12, 255, 254, $dpi, $dpi,
                  $height, $width, 1, "n";

# Create the RSR footer
my $footer = pack 'NNNNx8nnx2a4x3anx10Ca7',
                  256, $size, $size - 256, 58, 28, 50, 'PICT', "n", 128,
                  7, 'preview';

print $header, $data, $footer;

I'm the asshole. You wanna be a shit? You gotta go through ME.

I don't know nothing about Magick, but something is strange: A PICT image is - 512 Bytes of 0's - Pict header (didn't counted the bytes) - Image Data - 0x00FF A RSR image is - 260 Bytes RSR header - Pict header - Image Data - 0x00FF - RSR footer You have joined in my $header the RSR and PICT header, but you defined only a part of the PICT header, information as 24 or 32 bits color is omited. PICT header contain more information following $width, 1, "n"

Stupidity also evolves!

Oops. My bad. Up there where is says to Scale() the image, the ImageMagick libraries didn't do what I expected. So do it like this instead of that line: my $newheight = int((91 * $image->Get('height')) / $image->Get('width')); $image->Scale(width => 91, height => $newheight);

I'm the asshole. You wanna be a shit? You gotta go through ME.

Kawecki: I'm building my header based on ones that Poser itself made:

00000000   00 00 01 00  00 00 23 A4  00 00 22 A4  00 00 00 3A  ......#..."....:
00000010   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000020   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000030   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000040   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000050   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000060   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000070   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000080   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000090   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000A0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000B0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000C0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000D0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000E0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000F0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000100   00 00 22 A0  22 A0 00 00  00 00 00 5B  00 5B 00 11  .."."......[.[..
00000110   02 FF 0C 00  FF FE 00 00  00 48 00 00  00 48 00 00  .........H...H..
00000120   00 00 00 00  00 5B 00 5B  00 00 00 00  00 01 00 0A  .....[.[........

And they're working fine.

I'm the asshole. You wanna be a shit? You gotta go through ME.

BTW, ones I generated with P3DO Explorer and with PICT2RSR both had similar headers. The P3DO one was identical, while the PICT2RSR ones was a little different. A P3DO one looks like this (different images on these, BTW):

00000000   00 00 01 00  00 00 2F 68  00 00 2E 68  00 00 00 3A  ....../h...h...:
00000010   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000020   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000030   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000040   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000050   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000060   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000070   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000080   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000090   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000A0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000B0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000C0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000D0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000E0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
000000F0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000100   00 00 2E 64  2E 64 00 00  00 00 00 5B  00 5B 00 11  ...d.d.....[.[..
00000110   02 FF 0C 00  FF FE 00 00  00 48 00 00  00 48 00 00  .........H...H..
00000120   00 00 00 00  00 5B 00 5B  00 00 00 00  00 01 00 0A  .....[.[........

While the PICT2RSR one seems to be coming out a little different (but both work): 00000000 00 00 01 00 00 00 21 AC 00 00 20 AC 00 00 00 3A ......!... ....: 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000100 00 00 20 A8 20 A8 00 00 00 00 00 5B 00 5B 00 11 .. . ......[.[.. 00000110 02 FF 0C 00 FF FE 00 00 00 48 00 00 00 48 00 00 .........H...H.. 00000120 00 00 00 00 00 5B 00 5B 00 00 00 00 00 A1 01 F2 .....[.[........

I'm the asshole. You wanna be a shit? You gotta go through ME.

Actually, the PICT2RSR one has a few more bytes on the RSR header:

00000130   00 16 38 42  49 4D 00 00  00 00 00 00  00 5B 00 5B  ..8BIM.......[.[
00000140   47 72 89 70  68 81 81 AF  00 01 00 0A

And like I said, the first thing I found in the Poser RSRs was that everything up to and including the first Newline (0x0A), when removed and replaced with any PICT header regardless of the data therein, will allow it to be opened as a PICT (and the height and width information in that header are either ignored or at least superceded by the later data).

I'm the asshole. You wanna be a shit? You gotta go through ME.

And here's the proof B^)

I'm the asshole. You wanna be a shit? You gotta go through ME.

Attached Link: http://www.xfx3d.net/utilities/

[XFX Utilities : Thumb-Maker](http://www.xfx3d.net/utilities/)

I'm the asshole. You wanna be a shit? You gotta go through ME.

I don't know, according to the fromat of PICT2 there are missing 78 bytes and the information of 24 or 32 bits is important because will define if the thumb has or not alpha information.

PICT Header from my program:

// Write header
WriteBlobShort(&bptr,0); // 0x2D82 size
WriteBlobShort(&bptr,0); // size_rectangle.top
WriteBlobShort(&bptr,0); // size_rectangle.left
WriteBlobShort(&bptr,height); // size_rectangle.bottom
WriteBlobShort(&bptr,width); // size_rectangle.right
WriteBlobShort(&bptr,PictVersion); // 0x0011
WriteBlobShort(&bptr,0x02FF); // version #2
WriteBlobShort(&bptr,PictInfoOp); // 0x0C00
WriteBlobLong (&bptr,0xFFFFFFFFL); // 0xFFFE0000L); // FFFE0000
WriteBlobShort(&bptr,0x0000); //0x0048); // x_resolution ??
WriteBlobShort(&bptr,0x0000); // 0000
WriteBlobShort(&bptr,0x0000); //0x0048); // y_resolution ??
WriteBlobShort(&bptr,0x0000); // 0000
WriteBlobShort(&bptr,height); // frame_rectangle.top ??
WriteBlobShort(&bptr,0x0000); // frame_rectangle.left ??
WriteBlobShort(&bptr,width); // frame_rectangle.bottom ??
WriteBlobShort(&bptr,0x000); // frame_rectangle.right ??
WriteBlobLong (&bptr,0x00000000L); // 00000000
WriteBlobShort(&bptr,0x0001); // PictCropRegionOp
WriteBlobShort(&bptr,0x000A); // 000A
WriteBlobShort(&bptr,0x0000); // crop_rectangle.top
WriteBlobShort(&bptr,0x0000); // crop_rectangle.left
WriteBlobShort(&bptr,height); // crop_rectangle.bottom
WriteBlobShort(&bptr,width); // crop_rectangle.right
WriteBlobShort(&bptr,PictPixmapOp); // 0x009A
WriteBlobLong (&bptr,0x000000FFL); // base_address
WriteBlobShort(&bptr,row_bytes | 0x8000); // 816C (91x4) (91x3)
WriteBlobShort(&bptr,0x0000); // bounds.top
WriteBlobShort(&bptr,0x0000); // bounds.left
WriteBlobShort(&bptr,height); // bounds.bottom
WriteBlobShort(&bptr,width); // bounds.right
WriteBlobShort(&bptr,0x0000); // pixmap.version
WriteBlobShort(&bptr,0x0004); // pixmap.pack_type
WriteBlobLong (&bptr,0x00000000L); // pixmap.pack_size
WriteBlobShort(&bptr,0x0048); // x_resolution
WriteBlobShort(&bptr,0x0000); // 0000
WriteBlobShort(&bptr,0x0048); // y_resolution
WriteBlobShort(&bptr,0x0000); // 0000
WriteBlobShort(&bptr,0x0010); // pixmap.pixel_type (16)
WriteBlobShort(&bptr,bits_per_pixel); // 0x0020
WriteBlobShort(&bptr,component_count); // pixmap.component_count
WriteBlobShort(&bptr,0x0008); // pixmap.component_size
WriteBlobLong (&bptr,0x00000000L); // pixmap.plane_bytes
WriteBlobLong (&bptr,0x00000000L); // pixmap.table
WriteBlobLong (&bptr,0x00000000L); // pixmap.reserved
WriteBlobShort(&bptr,0x0000); // source_rectangle.top
WriteBlobShort(&bptr,0x0000); // source_rectangle.left
WriteBlobShort(&bptr,height); // source_rectangle.bottom
WriteBlobShort(&bptr,width); // source_rectangle.right
WriteBlobShort(&bptr,0x0000); // destination_rectangle.top
WriteBlobShort(&bptr,0x0000); // destination_rectangle.left
WriteBlobShort(&bptr,height); // destination_rectangle.bottom
WriteBlobShort(&bptr,width); // destination_rectangle.right
WriteBlobShort(&bptr,0x0000); // transfer_mode // 0008 ????

Stupidity also evolves!

Now I need Bryce OBP and Vue VOB Format!!!!!!

Stupidity also evolves!

Well. Uhm... you have an account on XFX3d, kawecki. Users were transferred over when 3-DArena underwent massive changes. Your password is the same as it was for 3-DArena, and there's a password reset system now if you don't remember it. So try out my converter and take a look at the code. Except for the fact that it spits out a PNG, too, has a CGI wrapper to make ti web-based, and reads the data into the ImageMagick object from memory (the upload) rather than a file, it's using the same code as I posted up above. They do work, and as you can see in the screenshot above, they keep alpha channels too.

I'm the asshole. You wanna be a shit? You gotta go through ME.

I can't login with Firefox, I login and then opens a blank page. I logged with IE. The converter failed to convert properly rsr to png. With png to rsr it looks that is ok, the header is the full header, but I have no Poser here to check all

Stupidity also evolves!

I just made one or two modifications to how the data was being read in for some files, including both RSRs and TIFFs (in the former case, I wasn't looking in the right place for the temp PICT header to plug in, and in the latter case I was failing to downsample the colour depth first). That was a read issue, not a write one, though. It's fixed now.

I'm the asshole. You wanna be a shit? You gotta go through ME.

I also changed the apache configuration on the site to stop an issue that firefox was having with the site that I noticed, too. I think it worked. It seems to have at any rate. (Problem with firefox's handling of KeepAlive persistent HTTP 1.1 connections - I turned off Keepalive for Firefox, it doesn't seem to slow anything down)

I'm the asshole. You wanna be a shit? You gotta go through ME.

Attached Link: http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox-99.html

I finally managed to track down the link again, so here it is in all its gory details: the Resource File Format.

I've spent most of the day trying to figure this out, then found this thread and eventually worked my way all the way down to post #75 and the link to your "Thumb-Maker" app. TOO COOL!! I can now make P4 RSR thumbs 3 times taller and finally, with failing vision, see them once again! Incredibly helpful and generous of you XFX3d! Cant thank you enough!