Hi,
I am programming a utility application and need to include a rsr to png conversion routine in my code without recurring to any external programs, but I have not found the specification for that file formats.
That is needed to convert between files and using the data back and forth.
Does anyone where to find that file formats specs?

Links to useful threads.
http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2672406
http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2403024

Hey, the first thread just points back here! ;)

I'm looking for a way to convert pict image files to RSR (since that is the best that I can save for Bitmap with the plugin SDK being using - no PNG support).  I know that the PICT file is embedded minus the first 512 '0' bytes and have references to the format from Apple, but it would be so much better if there was source code (preferably C or C++, Java would suffice if it doesn't rely on to many other Java APIs).

Now, I've managed to read RSR files to extract the image for thumbnail display, but then I'm just getting the offsets and getting the information needed.  Reading blindly is one thing.  Writing something that is a valid RSR (that Poser can read) is another altogether.

Hard, oh so hard, to do a Google search.  RSR is useless as it encompases about fifty thousand different things other than Poser RSR files.  (Mac) Resource (Fork, Data, File) yields about three thousand ways to read/write these on a Mac using Resource Manager.  Useless again.  Just try a search of "Poser RSR" and see the limited results, most to P3OExplorer (can't be used here, this is a plugin that needs to do it 'natively'!).

Thanks,
Robert

I haven't tried writing a converter, but you can get the relevant formats at Wotsit (I absolutely love that web site). If you write the appropriate RSR header out in place of the PICT header, I expect that Poser won't have any trouble with it.

You can get the header and other relevant image file changes here.

 There's a link here for writing an RSR file header in Perl, which you might possibly find useful.

I've found Dodger's method of replacing the PICT header with an RSR Header and adding an RSR Footer.  Just about to try this and see what happens.

Wotsits is great, but do they really have a Poser RSR format spec?  Not that I know of. :)

I was going to try using libpng to do a PNG export, but this thing makes zlib look simplistic. Plus I don't know what conversion would be needed to make Cinema 4D's Bitmap format work with it. People forget that my plugin is a 1.5MB lib (hundreds of thousands of lines of code - even with C4D's SDK) at this stage.  This is one method in thousands dispersed in a couple dozen classes - can't spend a month writing a PNG exporter (things like IK, BVH import, Poser magnets, Point At, and so on and on to do before I die).  ;)  Realizing that I had code to extract a PICT from an RSR and an SDK means to export as PICT, I quickly dropped the PNG exporter idea (yay).

Perl - yuck! ;D  That code makes no sense to me (no Perl for me).  Plus, this is heavily tied to ImageMagick, something else that is useless to me.  I'd rather not have my plugin users dependent upon a stack of required dlls and external application requirements.

I post back if this works.

Thanks,
Robert

Well, dress me up and call me perty.  This would probably work if the saved PCT file was an 8BIM format, but it isn't and there is no option to save it as such.  So, the RSR header/footer trick may be working for all that I know, but since the format isn't the proper PICT format, Poser can't use it.

Now I have two choices:

• Just save a JPG as before, but the thumbnail will only be usable with my plugin (which handles PCT, JPG, and PNG formats through Cinema 4D's QT support).

• Use a generic PNG file and skip a tailored-to-order rendered bitmap of the scene as the thumbnail.

Sucky all around.  I really don't have patience to get too deep into this.  It is only part of a Pose file save which is a minutely small part of the overall massive plugin suite (11 coordinated plugins and growing).

Thanks,
Robert

I find writing an RSR way easier than reading (as there I got some problems ;-). Encoding an RSR for Poser is really easy: as the number of pixels is fixed in the header you just write out pixel after pixel line by line, so 3 or 4 bytes (if with alpha) of color information (that's what the 3/4 means in the header ;-)). There's a repeat count, too, should be in front of the color information... That's just from memory though, but should be all you need. Try kawecki's PNG to RSR converter on a few images or ask him and you'll easily find the algorithm to write out the RSRs.

Well, my application does not need to return anything to poser, but merely to show a thumbnail if there is a poser RSR and the PNG is absent.
Of course when browsing through the library, poser creates the png files, but in the case of Advanced Library, if there is no PNG thumbnail yet, no image is shown.
The SenoSoft's P3dO paid version utility  apparently can batch create the needed thumbnails, but I intend to make a utility that does not force my customer to purchase another software package.

The workflow I found useful is:

a) Convert the poser RSR to mac PICT format.  I found a lot of information about the fact that poser RSR are in fact mac resources containing a PICT image. The switch header method is wonderful. So far, I still have problems with transparency, but will try Dizzi's suggestion.

b) Convert the PICT to PNG with an appropriate graphics converter library. I use delphi, and there are a number of graphics manipulation and conversion libraries that can be embedded into the application.

JD

The later betas of AL can convert most RSRs natively, but some don't have the easy encoding and result in rubbish... Well, I'll look into those again sometime ;-)

In my case, my plugin doesn't really need to have the thumbnail shown in Poser, but since the pose file and thumbnail are being added to the current Runtime library, it would be nice to have a Poser-compliant thumbnail image.

I'm not really too hip on writing out the embeded PICT information into an RSR myself.  The header switch with footer didn't work with the type of PICT saved from the quick render in Cinema 4D to create the thumbnail image.  I note that some RSRs have different values than the header/footer Dodger supplied.  That means some values changes would need to occur in there - probably the Resource map offsets.

For C++, there aren't too many open-license (zlib-type) graphics libs available.  I just tried FreeImage yesterday and it was a catastrophe.  First, my plugin uses a plugin SDK so I can't just change the compiler/linker settings willy-nilly.  For instance, FreeImage wants LIBCMT to be ignored when its lib is included.  That created a ton of linker errors when the FreeImage.lib was added to my plugin project because the plugin API lib obviously needs LIBCMT (removing this ignore resulted in none of those linker errors, but FreeImage.lib had issues).  Can't work around that.  It also redefines several basic types already defined by the API (and FreeImage wants Initialize and DeInitialize wrapped at the start and end of main).  Dumped.  Of the two other alternatives, one has known issues and support was discontinued three years ago - nope.

Oversimplified me thinks...

Well, header+footer can only work, if your encoded image is exactly as long as the one you cut the header and footer off from, as resource information is stored at the end of the file... So if the offset to the resource at the beginning of the file points somewhere else because you're changing the length of the content, it won't work. The header+footer attempt probably only works well where the image isn't (RLE) encoded at all. First 4 bytes of RSR: Offset to first resource. Next 4 bytes offset to ResourceMap As it's high bytes first, resolving the address could go like that: (((adr[0]*256)+adr[1])*256+adr[2])*256+adr[3] Trying to remember what's else in there ;-9

I'm going to give the Resource map offset changes a try and see if that works - oh, that would be so nice. :)

The Resource header is 16 bytes in 4 byte (LONG) sections:

4: Offset from beginning of resource fork to resource data
4: Offset from beginning of resource fork to resource map
4: Length of resource data
4: Length of resource map

This information I have.

Use this as reference.

That worked!!  The image is a screencap from Poser 4 of the RSR created by my plugin in Cinema 4D. 8P

So, I used the RSR header/footer Byte arrays, but updated the Map offset and Data length to the PICT file size being embedded.  This code uses the SDK file access, but matching to other file accesses (C++ file stream, C file pointer, etc.) should be easily determined.  These are Dodger's template header/footer.

Quote -
// RSR Header (Resource Header, Reserved, and Resource Data header
UCHAR    RSRHeader[304] =
{
    // Resource Header (Constant - shouldn't need to be changed)
    // Rsrc Data Start | Rsrc Map Start    | Rsrc Data Len     | Rsrc Map Len*
    0x00,0x00,0x01,0x00,0x00,0x00,0x26,0x16,0x00,0x00,0x25,0x16,0x00,0x00,0x00,0x3A,
    // - Reserved -
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    // Start of Resource Data
    0x00,0x00,0x25,0x12,0x25,0x12,0x00,0x00,0x00,0x00,0x00,0x5B,0x00,0x5B,0x00,0x11,
    0x02,0xFF,0x0C,0x00,0xFF,0xFE,0x00,0x00,0x00,0x48,0x00,0x00,0x00,0x48,0x00,0x00,
    0x00,0x00,0x00,0x00,0x00,0x5B,0x00,0x5B,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x0A
};
// RSR Footer (Resource Map)
UCHAR    RSRFooter[58] =
{
    // Start of Resource Map
    0x00,0x00,0x01,0x00,0x00,0x00,0x21,0xAC,0x00,0x00,0x20,0xAC,0x00,0x00,0x00,0x3A,
    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x1C,0x00,0x32,0x00,0x00,0x50,0x49,
    0x43,0x54,0x00,0x00,0x00,0x0A,0x00,0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
    0x00,0x00,0x07,0x70,0x72,0x65,0x76,0x69,0x65,0x77
};
// IPPSaver.ConvertPCTToRSR - Write to file
//---------------------------------------------------------------------------
BOOL IPPSaver::ConvertPCTToRSR()
//---------------------------------------------------------------------------
{
    AutoAlloc    pctFile;
    AutoAlloc    rsrFile;
    if (!(pctFile && rsrFile))    return FALSE;

    // Open PCT thumbnail and RSR files (Must be MOTOROLA for RSR file!)
    if (!(pctFile->Open(poseFilename, GE_READ, FILE_NODIALOG, GE_MOTOROLA)))    return FALSE;
    poseFilename.SetSuffix("rsr");
    if (!(rsrFile->Open(poseFilename, GE_WRITE, FILE_NODIALOG, GE_MOTOROLA)))    return FALSE;

    // - Skip to first 0A byte
    UCHAR    c;
    do
    {
        if (!pctFile->ReadUChar(&c))                return FALSE;
    } while (c != 0x0A);
    LONG        datasize =    pctFile->GetLength()-pctFile->GetPosition();
    // Resource Map Offset (from start of file)
    LONG        offset =    datasize+304;
    // Resource Data Length = Resource Map Start-256
    LONG        length =    offset-256;
    // Resource Map Offset
    RSRHeader[4] =    (offset & 0xFF000000L) >> 24;
    RSRHeader[5] =    (offset & 0x00FF0000L) >> 16;
    RSRHeader[6] =    (offset & 0x0000FF00L) >> 8;
    RSRHeader[7] =    (offset & 0x000000FFL);
    // Resource Data Length
    RSRHeader[8] =    (length & 0xFF000000L) >> 24;
    RSRHeader[9] =    (length & 0x00FF0000L) >> 16;
    RSRHeader[10] =    (length & 0x0000FF00L) >> 8;
    RSRHeader[11] =    (length & 0x000000FFL);
    // Copy of Resource Header in Resource Map
    // - Resource Map Offset
    RSRFooter[4] =    RSRHeader[4];
    RSRFooter[5] =    RSRHeader[5];
    RSRFooter[6] =    RSRHeader[6];
    RSRFooter[7] =    RSRHeader[7];
    // - Resource Data Length
    RSRFooter[8] =    RSRHeader[8];
    RSRFooter[9] =    RSRHeader[9];
    RSRFooter[10] =    RSRHeader[10];
    RSRFooter[11] =    RSRHeader[11];

    // Write RSR Header
    if (!rsrFile->WriteBytes(&RSRHeader[0], 304))    return FALSE;
    // Copy PICT data to RSR file
    // - Write PCT data to RSR file
    for (LONG size = 1024; datasize; datasize -= size)
    {
        if (size > datasize)                        size = datasize;
        size =                                        pctFile->ReadBytes(&strBuf[0], size, FALSE);
        if (!size)                                    return FALSE;
        if (!rsrFile->WriteBytes(&strBuf[0], size))    return FALSE;
    }
    // Write RSR Footer
    if (!rsrFile->WriteBytes(&RSRFooter[0], 58))    return FALSE;

    // Close PCT and RSR files
    rsrFile->Close();
    pctFile->Close();
    return TRUE;
}

Thank you all!
Robert

Hi,

Here's the link for the resource file format:

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

Hope that helps

Martin

I already have the resource file format from Apple.  That wasn't the problem. The problem was setting the RSR data properly.  I've seen the format enough to know that it can get complicated (check out some of the larger thumbnail RSR files and see all of the spurious other resources in the file (fonts and such) - it can get complicated to traverse as Dizzi noted).  The main problem was what data to include and set (the 'Start of Resource Data' section of the RSRHeader array is very important and NOT part of the Resource file format - it is part of the PICT file format or the PICT resource - not sure which).

As you can plainly see, it now works (or the screencap is a world-wide conspiracy!) ;D

You probably were just lucky and it will stop working after that image ;-)

Hehe. I think I found my decoding problem. Those that didn't work are using 16bit per color not 24/32 ;-) Part of the pict header now obviously is (in that order): Bits per pixel (2 Byte) - I hope 32 or 16 are the only ones used in RSRs... Number of components (2byte) - 3: rgb, 4:rgba Bits per component (2 byte) - 8 or 5

Attached Link: http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2470224

Sorry about that. I need to remember to be more careful when I'm only half awake.

Thank you verily!  And I shouldn't post until I've done my p's and q's.  It turned out simpler than expected - once you see the forest from the trees. :)
Dizzi, is the RSR that I created 16-bit?  I do know that there is no Alpha stored in the saved PICT.

No, your image is correctly labled as 32 bit without alpha and decodes fine, but I got some 16bit PICTs to analyze (looks like it's using another encoding algorithm, too... maybe that's the meaning of one of the other bytes ;-)).

One thing that I found with these PICT images being saved from Cinema 4D is that some of them (only one so far) get mangled when Poser converts from my RSR into PNG.  Personally, I think that this is related to the PICT and not the RSR (I hope). :)

I can check your RSR if you want ;-)

An update to the code posted above (insert the red code):

    // Resource Data Length
    RSRHeader[8] =    (length & 0xFF000000L) >> 24;
    RSRHeader[9] =    (length & 0x00FF0000L) >> 16;
    RSRHeader[10] =    (length & 0x0000FF00L) >> 8;
    RSRHeader[11] =    (length & 0x000000FFL);
    // v1.2.1:    PICT Data Size
    RSRHeader[256] =    RSRHeader[8];
    RSRHeader[257] =    RSRHeader[9];
    RSRHeader[258] =    RSRHeader[10];
    RSRHeader[259] =    RSRHeader[11];
    // Copy of Resource Header in Resource Map
    // - Resource Map Offset
    RSRFooter[4] =    RSRHeader[4];
    RSRFooter[5] =    RSRHeader[5];
    RSRFooter[6] =    RSRHeader[6];
    RSRFooter[7] =    RSRHeader[7];

Thanks to Dizzi for finding the problem.  It was mainly a Poser RSR->PNG conversion corruption error, but this fixes that.  This sets the PICT header within the RSR file to match the size of the PICT data section.

Enjoy your weekend!

Robert

A couple of changes.  Noone seemed to notice that the second value in the RSR pict header replacement must match that in the file, so I've updated the code thusly (the header/footer arrays have not changed).  Now both Poser and my plugin like the RSRs. :)

// IPPSaver.ConvertPCTToRSR - Write to file
//---------------------------------------------------------------------------
BOOL IPPSaver::ConvertPCTToRSR()
//---------------------------------------------------------------------------
{
    AutoAlloc    pctFile;
    AutoAlloc    rsrFile;
    if (!(pctFile && rsrFile))    return FALSE;

    // Open PCT thumbnail and RSR files (Must be MOTOROLA for RSR file!)
    if (!(pctFile->Open(poseFilename, GE_READ, FILE_NODIALOG, GE_MOTOROLA)))    return FALSE;
    poseFilename.SetSuffix("rsr");
    if (!(rsrFile->Open(poseFilename, GE_WRITE, FILE_NODIALOG, GE_MOTOROLA)))    return FALSE;

    UCHAR    c;
    pctFile->Seek(512, GE_START);
    // Get Pict File Size (-512 header)
    if (!pctFile->ReadUChar(&c))                    return FALSE;
    UCHAR    pictFileSize0 =    c;
    if (!pctFile->ReadUChar(&c))                    return FALSE;
    UCHAR    pictFileSize1 =    c;
    GePrint("Pict Size: "+LongToString(pictFileSize0)+LongToString(pictFileSize1));
    // - Skip to first 0A byte
    do
    {
        if (!pctFile->ReadUChar(&c))                return FALSE;
    } while (c != 0x0A);
    LONG        datasize =    pctFile->GetLength()-pctFile->GetPosition();
    // Resource Map Offset (from start of file)
    LONG        offset =    datasize+304;
    // Resource Map Offset
    RSRHeader[4] =        (offset & 0xFF000000L) >> 24;
    RSRHeader[5] =        (offset & 0x00FF0000L) >> 16;
    RSRHeader[6] =        (offset & 0x0000FF00L) >> 8;
    RSRHeader[7] =        (offset & 0x000000FFL);
    // v1.2.1: Resource Data Length
    RSRHeader[10] =        pictFileSize0;
    RSRHeader[11] =        pictFileSize1;
    // v1.2.1:    PICT Data Size
    RSRHeader[258] =    pictFileSize0;
    RSRHeader[259] =    pictFileSize1;
    // v1.2.1:    PICT File Size
    RSRHeader[260] =    pictFileSize0;
    RSRHeader[261] =    pictFileSize1;
    // Copy of Resource Header in Resource Map
    // - Resource Map Offset
    RSRFooter[4] =        RSRHeader[4];
    RSRFooter[5] =        RSRHeader[5];
    RSRFooter[6] =        RSRHeader[6];
    RSRFooter[7] =        RSRHeader[7];
    // - Resource Data Length
    RSRFooter[8] =        RSRHeader[8];
    RSRFooter[9] =        RSRHeader[9];
    RSRFooter[10] =        RSRHeader[10];
    RSRFooter[11] =        RSRHeader[11];

    // Write RSR Header
    if (!rsrFile->WriteBytes(&RSRHeader[0], 304))    return FALSE;
    // Copy PICT data to RSR file
    // - Write PCT data to RSR file
    for (LONG size = 1024; datasize; datasize -= size)
    {
        if (size > datasize)                        size = datasize;
        size =                                        pctFile->ReadBytes(&strBuf[0], size, FALSE);
        if (!size)                                    return FALSE;
        if (!rsrFile->WriteBytes(&strBuf[0], size))    return FALSE;
    }
    // Write RSR Footer
    if (!rsrFile->WriteBytes(&RSRFooter[0], 58))    return FALSE;

    // Close PCT and RSR files
    rsrFile->Close();
    pctFile->Close();
    return TRUE;
}

Take care,

Robert