Hey
Peter,
thanks
for the in-depth feedback. I was not aware that there can be
both flat and deep data in a single image. Are you aware of
any implementations
that
I could use to give this a try? e.g. does nuke read these
correctly and is there a way to generate such images? I have
a very strong use-case for
this
depending on how good this works.
Cheers,
Thorsten
---
Thorsten Kaufmann
Production Pipeline Architect
Mackevision
Medien Design GmbH
Forststraße 7
70174 Stuttgart
T +49
711 93 30 48 661
F +49 711 93 30 48 90
M +49 151 19 55 55 02
address@hidden
www.mackevision.com
Geschäftsführer:
Armin Pohl, Joachim Lincke, Jens Pohl
HRB 243735 Amtsgericht Stuttgart
---
MOTIONBOX: New
film packages available (offer valid until June
30th)
SHOWREEL: Watch our latest Showreel 2017
ISO 9001: Mackevision is certified
according to ISO 9001:2015
SOCIAL: LinkedIn,
Xing,
Facebook, Twitter,
Behance, Vimeo
Hi Gonzalo,
Apologies for the confusion in my reply. Yes, this file only
contains deep image data, not flat. If you use the standard
EXR API to read the file, it will composite the samples
together to provide a representation of the image (see
ImfCompositeDeepScanLine.h in the OpenEXR source for more
details). This is exactly what's happening in your viewer
under the hood: all the deep RGBA data is being composited to
give you a single 'beauty' image representation. This
compositing operation is slow because it has to process every
deep sample in every scanline before it can be output to your
framebuffer.
Storing deep and flat within the same file is possible and
supported. In my previous reply I assumed this was exactly
how this file had been written, with the deep and flat parts
representing the same data. The main reason to do this is for
speed: the deep and flat parts would represent the same data,
but the flat part is much faster to read when deep samples are
not required. Since the deep file is already quite large,
storing the flat part in the file as well is probably
justifiable. The flat image would be stored as part 0, so an
image viewer would read that by default, and ignore the
deepscanline representation of the same channels in part 1. A
viewer might offer a "deep image mode" to read the deep
instead of the flat. In that case it would likely use the
dedicated deep pixel API in OpenEXR so it can generate useful
analytical data such as Thorsten's sample count visualisation
or a 2.5D/3D representation of the data.
As Thorsten suggests, it may be a more common practice to
write that non-deep representation of the data as a completely
separate EXR file. There are pros and cons to doing this:
although this doesn't take more disk space than a single
combined file and makes it easy to remove the deep image if it
is later deemed unnecessary, it leads to more files in the
system and possible confusion about which deep image goes with
which flat one, particularly if only one of the files is later
overwritten.
Peter
On 30/05/17 02:37, Thorsten Kaufmann
wrote:
Hey
Gonzalo,
deep
and flat do not live in different parts of the file. It is
essentially the same data. With deep files each sample for
every pixel in every channel is saved separately
whereas
in flat the samples are merged into a single pixel in
every channel.
I
have seen people do things like saving a flat beauty and
deep “other” channels like position or the likes, but that
does not really make much sense to me.
My
guess would be that you’d have to write a separate
non-deep version of the EXR if you want to be able to
choose.
Cheers,
Thorsten
---
Thorsten Kaufmann
Production Pipeline Architect
Mackevision
Medien Design GmbH
Forststraße 7
70174 Stuttgart
T
+49 711 93 30 48 661
F +49 711 93 30 48 90
M +49 151 19 55 55 02
address@hidden
www.mackevision.com
Geschäftsführer:
Armin Pohl, Joachim Lincke, Jens Pohl
HRB 243735 Amtsgericht Stuttgart
Hi, Thorsten.
El 29/05/17 a las 04:21, Thorsten
Kaufmann escribió:
Hey there,
so there is no "deep
vs. beauty". It's simply a deepscanline image. I don't
think it is even possible to mix
deep and non-deep
images, is it?
No, but my understanding was that the
deep and beauty info live in different parts of the image.
Deep is not an
additional set of information but it stores all of the
regular information in a more granular way.
So there is both more
data to read and you more "work to do" (to blend the
individual samples) which makes
reading deep images
slower. The amount of additional samples depends a lot
on the type of image you have
motionblur, dof
making things way worse and of course on the renderer's
implamentation and if samples
are merged and how.
So you mean that the beauty pic is composed of the deep
samples? There's no decoupling of the deep and beauty
data? That doesn't sound right. I remind you I only want
to load the beauty picture, not the deep data (of which I
have no use for now).
Thank you for looking into this,
--
Gonzalo Garramuño
_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel