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 thorsten.kaufm...@mackevision.com www.mackevision.com<http://www.mackevision.com/?utm_source=E-Mail-Signatur&utm_medium=E-Mail&utm_campaign=Mackevision-Link> Geschäftsführer: Armin Pohl, Joachim Lincke, Jens Pohl HRB 243735 Amtsgericht Stuttgart --- MOTIONBOX: New film packages available<http://www.mackevision.com/motionbox/motionbox-new-film-packages-available/?utm_source=E-Mail-signature&utm_medium=E-Mail&utm_campaign=motionbox-offer> (offer valid until June 30th) SHOWREEL: Watch our latest Showreel 2017<http://www.mackevision.com/references/mackevision-showreel-2017/?utm_source=E-Mail-Signatur&utm_medium=E-Mail&utm_campaign=Showreel-2017> ISO 9001: Mackevision is certified according to ISO 9001:2015<http://www.mackevision.com/company/?utm_source=E-Mail-Signatur&utm_medium=E-Mail&utm_campaign=iso-company-link> SOCIAL: LinkedIn<https://www.linkedin.com/company/mackevision>, Xing<https://www.xing.com/companies/mackevision>, Facebook<https://www.facebook.com/mackevision/>, Twitter<https://twitter.com/Mackevision>, Behance<https://www.behance.net/mackevision>, Vimeo<https://vimeo.com/mackevision> From: Openexr-devel [mailto:openexr-devel-bounces+thorsten.kaufmann=mackevision...@nongnu.org] On Behalf Of Peter Hillman Sent: Montag, 29. Mai 2017 23:48 To: openexr-devel@nongnu.org Subject: Re: [Openexr-devel] Slow deep exr 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 thorsten.kaufm...@mackevision.com<mailto:thorsten.kaufm...@mackevision.com> www.mackevision.com<http://www.mackevision.com/?utm_source=E-Mail-Signatur&utm_medium=E-Mail&utm_campaign=Mackevision-Link> Geschäftsführer: Armin Pohl, Joachim Lincke, Jens Pohl HRB 243735 Amtsgericht Stuttgart From: Gonzalo Garramuño [mailto:ggarr...@gmail.com] Sent: Montag, 29. Mai 2017 14:20 To: Thorsten Kaufmann <thorsten.kaufm...@mackevision.com><mailto:thorsten.kaufm...@mackevision.com>; openexr-devel@nongnu.org<mailto:openexr-devel@nongnu.org> Subject: Re: [Openexr-devel] Slow deep exr 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 Openexr-devel@nongnu.org<mailto:Openexr-devel@nongnu.org> https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
