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

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

"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 only use C and Assembler in parts where speed is important.

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?

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

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.

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

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

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

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

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

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.

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

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

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

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 ????

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

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

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

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!