For me, P3dO is the content manager of choice.

Poser the Program – 8. Strategies

Poser Render Passes

Although various configurations can be setup via Material Room menus, and can be managed through the Simple interface, this topic is considered Intermediate level. Various causes can cloak my atmospherics: This article presents lists the Material Room nodes as well as various Render Settings, and their availability in recent Poser versions.

Render Settings

In the previous article it’s discussed how the Poser Gamma mechanism not only brightens up shadows and shades to compensate for the lack of radiosity and atmospheric scattering as can be found in real-life scenes, but also helps to add up lighting components like diffuse, specular, reflection and the like, especially when such components can be considered rather independent.

In some cases however, such components come to us in a ‘’ blend’, that is: more of one implies less of the other, which makes them far from independent. For example:

In those cases, the Gamma mechanism turns into a burden, instead of a benefit, when it includes the blending itself. I went through all the math (see last part of this chapter), and through a load of test renders, and my findings are:

Reverting the Gamma Sandwich

Just like this: The Fresnel_Blend is packed between two Gamma’s at the input side to take the effect out of the Reflect and Refract, and an inverse Gamma at the output side to put the effect back in again. Note that the Gamma node is not applying Gamma (darkening), but its inverse: Gamma Correction (brightening). This can be applied to all kinds of blending nodes: Fresnel_Blend, Edge_Blend, Color_Math (Blend), ColorRamp, you name it. It cannot be applied to the Fresnel node itself, as one cannot take the Gamma out of the reflections / refractions before they get blended.

Just leave Gamma out

The second best option, it distorts but not that much. Just apply the mentioned nodes as they come, apply transparency as it comes, it feels like “doing nothing”. But it also means: use Values for blending amounts and transparency, avoid using Color-swatches at any cost, and when using image-maps do set their Gamma values to 1.0 to bypass the mechanism.

This is the method followed automatically when the Fresnel node is used.

The use of Gamma = 1.0 for Transparency in all PoserSurface definitions in the scene can be enforced with the changeGamma scripts.

Manual adjustment

Older textures for characters offered a way to mimic advanced skin effects, like translucency and scattering. A small portion of red was removed from Diffuse (turning white into (245,255,255) a very mild cyan) and put back in again in the Ambient slot (turning black into (10,0,0) a very deep red). When rendering without Gamma, as was common in those days (Poser before version 10) this resulted in white (multiplied by any image map) plus a mild reddish glow.

However, when Gamma is turned on, the ratio gets distorted, the brightest component – the cyan in here – gets the upper hand, and all characters got the “smoking zombie look”.

Like this, left Andy without Gamma, right Andy with Gamma, same material and lighting: A closer look at Transparency

Consider an object, having a (surface) transparency of T=90%. When a direct (say 100%, white, point) light is illuminating the scene, this object will show the following behavior:

So at first sight I’ve got a choice: either the object is too bright and the shadows are right (no Gamma to transparency), or the object is fine and the shadows are too dark (Gamma on transparency too). At second sight, more effects have to be considered:

Actually, all the four elements mentioned above (all except the shadow mentioned first) add up to make one result. So how can be predict what happens when a gamma sandwich is applied to all that? We can be sure something gets distorted, as it would be a miracle when all things turned out equal. I do need math, figures and a lot of tests to get it sorted.

That’s for the next part of this chapter. For short: the Gamma mechanism, even when not applied to transparency itself, will produce a somewhat distorted result as it alters the balance between the ‘front’ and ‘behind’ scenes in the result. But when transparency itself is excluded from Gamma, then 1) I’ll get the best shadows which behave in sync with the other shadows in the scene and 2) I’ll get the least (and eventually most manageable) distortion, compared to when Gamma is included into the transparency.

So, I consider it best to treat Transparency as a value ‘thing’, I’ll avoid using color swatches to determine it, any image map involved will get Gamma=1.0, and I’ll use the various scripts to enforce that all over my scene materials.

The math and the figures

For those who want to check out on my findings themselves.

Plain Blending

Consider two inputs, A and B, blended together in an x-to-(1-x) ratio. More of A implies less of B and vice versa. For instance, reflection blended with diffuse (a shiny surface), of with refraction (Fresnel).

Some results, for Gamma 2.2 and blend ratio x set to 70%:

Consider A the lighting level in front of the transparent object, B behind it, for transparency T. More transparency means more of B (transmission/refraction), less transparency means more of A (diffuse/reflection). Transparency induces internal reflection/diffusion within the object. For a simple illustration: at transparency 90%, 10% with be reflected/diffused from the front while 90%x90%=81% shines through, passing front and back surfaces. The remaining 100-10-81=9% results from internal reflection / diffusion, leaving the object while bouncing around.

Some results, for Gamma 2.2 and Transparency set to 70%:

So in case of blending / transparency, I prefer values, I avoid color swatches, and when applying images I set their Gamma to 1.0.

Although various configurations can be setup via Render Settings (Poser 10, Pro 2010 and up), this topic is considered Intermediate – and sometimes Advanced – level.

When it comes down to Gamma Correction, there are a lot of stories. About gamma, images and devices, and on the application of the gamma function in Poser rendering. Some of those are close connected, other stories are hardly related. Unfortunately, all stories tend to get mixed up in forum threads, manuals and alike. Let’s tell them all, in a sort of organized way. Gamma and Devices

Output devices (at the end of any workflow, step A in the scheme above), like TV sets, PC monitors as well as newspaper pages all have in common that when they display an image, the midtones are darkened, the shadows lose detail while the brights gain some. From electronics, and from image handling as well, this loss of brightness is known as “gamma distortion” of “gamma effect”. Lots of people find this reduction of image brightness rather unpleasant for various reasons, some of which even go back to our natural roots having hunters and prey hidden in the darks.

A way to overcome this is to adjust the image before it gets displayed, by an “inverse gamma” or “gamma correction” effect (start of the workflow, step B in the scheme above). This brightens the midtones, and enhances the details in the darks at the cost of losing some in the brights. When such a corrected image is displayed, the “gamma inversion” embedded into the image and the “gamma distortion” of the device cancel each other out, and the image is displayed as it was intended, and as we are pleased to see it. This is how JPG (for pictures) and MPG (for movie footage) came to life: these formats have the gamma correction embedded as prescribed by their format standard; such in contrast to BMP, and raw image data. And so, this way of work proves fine for newspaper and magazine printers as well as TV sets and movie projectors which don’t have the processing power (‘intelligence’) on board to adjust images or movie frames on the fly.

TV sets etc. have to work with images and frames that have a standardized correction embedded into them. But they only approach that standardized gamma effect themselves. So they only can display the images as being “not too far off”. PC’s and the like have an advantage. They can open the image and correct for the standardized correction before (or when) sending the image data to any user application. This is step D in the scheme, called linearization.

And then the application can send its results to the video driver / video card which then communicate with the monitor. This offers the opportunity to establish correction curves for a specific monitor. Either by loading a brand and type specific profile from the manufacturer or even by measuring the monitors input/output response periodically, to compensate for aging as well. On a multi-monitor system, each one even can have its own profile, so an image keeps its exact appearance when dragged from one device to another. This is step C in the scheme, usually referred to as Color Management.

Summarizing: given the behavior of my monitor (A), image formats (B) are made up to compensate and with a dumb device in the middle, both cancel out to give me the proper image in result. With an intelligent device in the middle, both actions can be compensated for (monitor A by driver C, image format B by image handler D) so also the application in the middle can make proper results based on proper (‘linear’) inputs, and without having to worry about image formats and device characteristics.

So, in my PC, if the operating system / application deals with image formats and if the driver/card deals with monitor profiles, every type of image will behave ‘pure’ from an application input/output point of view. Great! Unfortunately, there are two ifs in this.

On the output side, PC video driver/cards have the profile handling capacity for say 10 years now (from 2005 on), but native (motherboard) video and laptops can only do so for say 5 years (2010 and on), while smartphones and tablets hardly do, and whether my laptop is feeding gamma-corrected streams to my TV-set is quite questionable. So images might look different from my PC monitor.

In cases the output handling abilities fall short, some applications offer the adjustment themselves, while others don’t. Some applications put in some adjustment anyway. In either case, a single image is shown in different ways by different applications onto the same screen. Unfortunately, there is no way to tell which one is right, although Photoshop can come close once I master its Color Management settings. And there are not that many ways for user-adjustment. Poser creates render results in 16-bit per color EXR format, and does quite a nice job in showing it on screen. Anyway, there are no settings or dials to affect that.

On the input side, some versions of operating systems do offer routines for proper image handling, some don’t. Even if they do, it’s up to the application to call for them instead of reading out the image data itself. I don’t have to figure out the details of this, it’s easy to test: make an image, save it in bmp as well as jpg format, and open both in my application at hand (with the same settings etc.). Do both show the same result? Then all is fine. If not, the jpg needs its embedded gamma-correction taken out, or has so but not to the right amount yet. Sometimes I can correct for that, either by opening it with adjusted settings, or by correcting for it in pre-production, with my image editor. This is called: linearizing the workflow. Poser (7 and up) users can rest assured: an image will show the same way whatever format is used.

Some test results, with a BMP and a JPG with an embedded profile:

Gamma and Poser

All in all, Poser works fine with all image formats and all output devices. I do not need any adjustments for that, Poser offers a “linear workflow”, especially in the design stage. But the great story is: Poser offers an optional non-linear rendering as well. In that, it first darkens all images, footage and colors around (step E in the scheme), and then it renders (step R). This will create quite a dark render, including shading and shadows. And with dark highlights as well, with quite a reduced risk on overlighting. Then it un-darkens the render result, step F in the scheme. From that, I can export the image for any further handling as required.

This sandwiched rendering will make all surfaces reappear at about their original colors and brightnesses as steps E and F are intended to cancel out. But all darkening that occurred during the rendering itself, like the shading and shadowing, will be brightened up considerably as these receive the post-render treatment from step F only. Highlights will be brightened a bit as well, but not to an overlighting level. In short: this sandwich process of darkening first and un-darkening later will just soften the darks and highlights, contributing to a more pleasant and more realistically looking image.

So, how to do the (un)darkening? Poser offers the gamma function for this, and that was just an arbitrary choice. They could have used another function as well, like exposure, but they didn’t. That gamma function is driven by a single (“gamma”) parameter. Each value larger than 1 will soften shadows and highlights, but values over 4 will create very artificially looking results. Values around 2 do very well for photorealistic renders. Values smaller than 1 (and preferably larger than 0.25) will have the opposite effect, which might be desired in comic styles.

Note on the method:

This Gamma-sandwiching approach is one of the available strategies. It works about as required for shadows as well as for highlights, and it’s easy to implement as it just adds a pre-render and a post-render step but leaves the rendering itself as is. Other 3D software (like Vue) works likewise. Very recommended, and discussed in various articles on this site. Other ways are:

Note on the Gamma value:

The Gamma value applied in Poser is a trade-off. For scenes with mainly or only direct lighting, a value below but close to 2.0 will produce the best shadow softening but when IDL gets the upper hand, lower values (towards 1.0) will produce better results. This is because the Gamma Correction includes compensation for radiosity of ceilings, walls etc. and with IDL, the lighting itself is catering for that itself. On the other hand, adding up very dissimilar light sources / surface components works best with gamma values just below 2.0 while adding up quite similar lights or about equally bright components works best with values even over 3.0. But… there is only one gamma to serve all. As a result, the industry standard 2.2 for device handling is considered a reasonable trade-off for Poser as well, even though both are completely unrelated.

Gamma and Confusion

So there are two rather unrelated processes. One for putting images onto output devices and for taking their effects out to enable applications to serve normally (represented by steps A, B, C and D in the scheme). And one for softening shadows and highlights in Poser renders to establish a more (photo)realistic look and feel, represented by steps E and F in the scheme.

The first utilizes a “gamma function” with a parameter value around 2 as this represents most output devices quite reasonably. In formal image format standards the value 2.2 is prescribed. The second utilizes the same gamma function, and a parameter value around 2 happens to present a pleasant result, and supports photorealism quite well.

So both processes happen to have the same mathematical function and the same optimal input value for it, in common. That’s their only relationship. Hence, don’t bother about all gamma-fuzz in forums, google, Wikipedia and the like, and don’t bother about monitors, calibration, and other output devices. They address the steps A, B, C and D from the scheme quite well. But I can freely choose whether or not to use the Gamma process in my Poser rendering, and I can freely choose my gamma value with it, as steps E and F in the scheme are separate ones. However, for photoreal’ish results, using the Gamma process with the default 2.2 value is much recommended.

Poser Details

The overview above mentioned the benefits of using the Gamma Mechanism offered from Poser 10 and Poser Pro 2010 up. The mechanism however has some drawbacks as well:

For Poser 9 and earlier, the Gamma node is available as well. This is meant for those cases where Poser is not taking any embedded brightness corrections out of the image properly. The node cannot be used to build the Gamma Mechanism myself, as that is a sandwiching process of which the nodes can only affect the input-part. One can however do the output-part of it in post. It’s quite elaborate though, to add the gamma node for every image map and color swatch in all material definitions in the entire scene.

The math of Gamma

Okay, let’s go for it. This is the Advanced part.

Say, an object in the scene has a color D. That is, I’m not interested in its hue, but the brightness is its Diffuse_Color or D between 0..100%. Let’s pick 70%.

With the Gamma mechanism enabled, the pre-render pass will turn that into Dg and for g>1, by default g=2.2, that will result in a darkening as for instance 0.72.2 = 0.46. When rendering, shading (like Lambert) darkens the sides of the object with respect to the lights, and any other object standing in the light casts shadows onto my object as well. This shading and shadowing actually multiplies areas of the object with S, between 0..100% also, say 20% at specific points. That turns the brightness of those spots to S*Dg or 0.2*0.46=0.092 in the example. The post-render pass then will turn the final result into (result)1/g which is a brightening, from the formula ( S*Dg )1/g = S1/g *D. The spots on the object without shading and shadow result in 0.460.45=0.70 while the spots with it result in 0.0920.45=0.34. Without the Gamma passes, the spots with shading would have resulted in 70%*20%=0.14 – a much darker result.

So from the formula and the example figures I learn that the object color will go untouched (70% remains 70%) while the shading and shadowing gets brightened (34% instead of 14% in the result, which is like multiplying with 0.485 (=0.200.45) instead of 0.20).

Colors, Images and Values

Now let’s look at the result of a diffuse component, with color D, an image map M attached to it adjusted with “render gamma”, and with value d, having an image map m attached to it adjusted with a custom gamma value h (1 or anything else). Then the final result will be ( S* Dg * Mg * d * mh )1/g = S1/g * D * M * d1/g * mh/g as the shading and shadowing S will get brightened up as required, the value d went untouched by the pre-render pass and hence will appear brightened up in the result as well, and the image m is assigned its own adjustment. So the total effect is different from just having a brightened up shadow on an unaffected object. The color swatch D and its image map M went unharmed, the result for the other image map is my own choice, but the value part results in a brightening up as it was ignored in the pre-render pass. Hence, when rendering with Gamma ON, I’d better set all value parts in PoserSurface to either 0 or 1, or face an additional brightening. This also implies that when I do want a brightness reduction, I have to blend that into the color swatch. For instance, a metal reflects with an orange color RGB (100%, 50%, 0) and reflectivity 80%. Then I should not set the color to the Reflection_Color and the 80% to the Reflection_Value, but I should assign the overall RGB (80%, 40%, 0) to the color swatch instead and set the Value to 1.0. Otherwise, my reflections will be too bright when rendering with Gamma. And without Gamma, it doesn’t matter.

Most components of PoserSurface have a color swatch. Alternate_Diffuse and Alternate_Specular even don’t have a value slot. Bump and Displacement do have a Value only, but anything plugged in those should not have any Gamma mechanism assigned. Bump maps for instance should have their Gamma = 1.0 in Texture Manager.

The only components requiring explicit attention are the ‘blenders’, like Edge_blend, Fresnel, but Transparency too. These components blend colors, images, scene reflections and the like based on a value or image map. Should they participate in the Gamma mechanism (like Diffuse etc.), or should they bypass it (like Bump/Displacement?). For short: they should participate as least as possible, and bypass as much as possible. See the next article for details.

Combining Components

So far so good, for components considered separately, and for the effects on shading and shadows. But what happens when components are combined and added up? That’s like two projectors, each presenting its own image on the wall.

In nature, our eyes will adjust to the increased lighting levels. In image handling such a thing is not possible, and for ages programs like Photoshop blend layers using the Screening method, which mimics the behavior of photographic film or its modern electronic equivalents. Film behaves about as follows: when a ray hits the film, there is a possibility, a change p1, that the film responds to it, and so there is change 1-p1 that the film remains unlit. When a second ray, either from a later moment, or from another source, or from opening the diaphragm further, hits the same spot on the film, there again is a change p2 of lighting the film, provided that it was unlit before that. So the change that the spot on the film is still unlit after two rays is (1-p1)*(1-p2) and hence the formula for light addition is: 1-(1-p1)(1-p2).

This is the way Screening works on PSD image layers: the inverses of the layers are multiplied and inverted again. For instance: one layer represents 30% brightness and the other 80%, then it results in 1- (1-0.3)*(1-0.8)=86% brightness. So lighting levels will increase but will not exceed 100%. Screening is considered the (industrial standard) way of work for adding light to an existing image (as multiplication is considered the right way to apply shadows and the like).

In Poser, without the Gamma mechanism, components will just be added up. In the above case, 30%+80%=110% and overlighting artefacts will ruin the render result. With the Gamma mechanism however, it will brighten the addition of the darkened components, that is: (0.32.2+0.82.2)0.45=0.84.

So, with Gamma about 2.2, the Gamma mechanism not only prevents overlighting and dims the highlights when specularity is added to regular diffuse. It also approximates the industry standard screening method very well, and should be considered the way forward to combine any components in the render result.  Whether they are diffuse and specular, diffuse and reflection, reflection and refraction, you name it. So they all have to respond to the Gamma mechanism to enable that. With exceptions for Bump / Displacement, which simulate or realize an alteration of the object geometry and do not “add light” or “subtract shadow” to the resulting render in any way. And with exceptions for the ‘blenders’ (Edge_Blend, Fresnel, Transparency, …) which also should avoid the Gamma mechanism as much as possible. Most scenes require some kind of environmental lighting, and Poser offers various ways to establish that.

One (recent) way is to enable InDirect Lighting (IDL) and to encapsulate the entire scene by a huge Sky Dome object, with an image mapped onto it, and having its surface normal pointing inward. This method uses extensive raytracing, and is resource intensive (memory, CPU power, render time, user patience). The dome sends its light rays inward into the scene, and from there the light gets bounced all around.

Another way is to put an Image Based Light (IBL) in the scene. An IBL is a kind of point light, with an image (frontally) mapped onto it, but with its light rays traveling inward towards the lamp position. What does that mean? Well, So the image is wrapped around the point light, and the bright yellow midsection is related to the mid-frontal part of the light. The red edges of the image all fold onto the mid-back side of the light, and all areas top side and bottom get the orange taint. That’s: frontally mapped.

See http://www.book.artbeeweb.nl/?p=3090 for details on translating the environment to IBL images.

In the image above, the IBL light resides at 0,0,0 between Andy’s feet. And the light rays are coming in, so Andy is colored yellow at its front, red at its back and orange at his top, sides and bottom.

Tip: for IBL lights, shadows should be OFF. As those lights cannot be placed but can be rotated (directed) only, and because light rays are considered coming in towards that point of interest, shadows from IBL lights tend to get somewhat unnatural, to say the least. The ball next to Andy uses the probeLight image mapping which offers the same mapping and image as used for the IBL, so the IBL effect is exaggerated in this scene, to illustrate the effects of mapping and of the lighting direction. As far as mapping is concerned, probeLight works well on a basic Poser Ball, and just offers some extras for tuning image appearance and some squeezing and stretching compared to just plugging in the image_map itself. The Hires ball however turns out quite hard to orient properly which becomes apparent when an image is applied to it.

As IBL serves either as an extra or as a replacement of an IDL sky dome, the remaining question is: can the IBL-image be mapped onto such a dome. Yes it can, and it works immediately on the geosphere and hemisphere from the regular Poser content, and on Bagginsbill’s EnvSphere and EnvHemisphere. Bagginsbill’s EnvDome offers a slight shift in mapping, which has to be compensated for. (V_Scale is doubled, and V_Offset is set to -1).

No, Poser does not support selective lighting.

However, Poser does support rendering on a per-light basis (menu Scripts > RenderControl > RenderPasses)

and on a per-object basis. (menu Scripts > Partners > Dimension3D > Render Content)

This way one can obtain a lot of half-products (“render passes”) which in turn can be combined in post. Usually, stacking the images as layers in an image-handling program like Photoshop, with the layers set to Screen mode, is the way forward. A tutorial on Poser Render Passes can be found at http://www.book.artbeeweb.nl/?p=388 .

In various cases, it might become handy to have lights that shine in preview only and do not affect de render result. This can be done easily, but requires the use of the Advanced interface to the Material Room. The options required are not available through the Simple interface.

Open de Light features in Material Room, and black out the Diffuse and Specular entries. Note: under IDL (InDirect Lighting) rendering conditions, all objects in the scene behave as a light, but diffuse only (no highlights). IDL lighting does not show in preview. But IBL (image based, direct) lights do show in preview, producing the appropriate local colors as well. So, in order to approximate IDL conditions – like a sky dome – in preview: add an IBL with the same dome image, and have its Diffuse channel blacked out (to have it switched OFF at render time).

Do pay attention to the appropriate orientation of the image, though!

In various cases, it might become handy to have lights that produce highlights only, or just no highlights at all. This can be done easily, but requires the use of the Advanced interface to the Material Room. The options described below are not available through the Simple interface. When I open the properties of a Light in Material Room, I see

The generic Color and Intensity are multiplied to one result as any regular Color/Value pair in the material definitions, and used in preview. The two latter ones are used in the Poser render only, multiplied by the generic Color and Intensity. So:
[null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.87.01.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.87.01.jpg", "formatted_filename": "PMRA", "rendered_width": 290, "rendered_height": 165}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.87.02.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.87.02.jpg", "formatted_filename": "PMRA"}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.87.03.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.87.03.jpg", "formatted_filename": "PMRA"}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.99.01.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.99.01.jpg", "formatted_filename": "PMRA"}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.99.02.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.99.02.jpg", "formatted_filename": "PMRA"}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.98.01.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.98.01.jpg", "formatted_filename": "PMRA"}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.98.01.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.98.01.jpg", "formatted_filename": "PMRA"}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.97.01.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.97.01.jpg", "formatted_filename": "PMRA"}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.97.02.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.97.02.jpg", "formatted_filename": "PMRA", "rendered_height": 500}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.97.03.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.97.03.jpg", "formatted_filename": "PMRA", "rendered_height": 500}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.97.04.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.97.04.jpg", "formatted_filename": "PMRA"}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.95.01.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.95.01.jpg", "formatted_filename": "PMRA"}, null, {"document_url": "http://www.book.artbeeweb.nl/tag/poser/", "unformatted_src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.94.01.jpg", "src": "http://www.book.artbeeweb.nl/wp-content/gallery/postpmra/PMRA.94.01.jpg", "formatted_filename": "PMRA"}, null]