OpenEXR DWA compression should not apply to non-color data passes
Open, ConfirmedPublic

Description

Linux Mint 17.3

Blender Version
2.78c

I write you because i've been testing alot with DWAA and DWAB. But there are major features missing. First of all. Blender need a Compression Tab kind of Setup button. I dont find anything in the release build 2.78c.
I uploaded a screenshot from the compositing app Natron to explain what i mean.

Second important thing is to make sure which passes get compressed and which are not. So it would be a good idea to create checkerboxes on each layer with a boolean description of "i want to compress this layer or not"

Layers with Capital letters not gonna get compressed. please read more in the foundry forum about that topic.: http://community.foundry.com/discuss/topic/125476

Cheers.

Details

Type
Bug
Aaron Carlisle (Blendify) closed this task as Archived.Apr 16 2017, 6:30 PM
Aaron Carlisle (Blendify) claimed this task.

Hi, while we love to hear these ideas, this is not the right place for them.
This website is mainly used to track bug reports and not feature requests.
But luckly, there are some other nice solutions you can take,
so please use one of the other forms of communication listed below:

Hmm, Not nice to hear.. I think you dont get it.. ITs not a missing feature or a nice to have, its essential. The entire DWAA and DWAB Support is useless... because with the actuall methode you compressing all Renderlayers.. like ZDeph and other Aux channels. By doing that you entirely kill the Renderlayer...Its worthless to use it. I wrote it here because you need to Fix this ASAP, otherwise no serious Artist should or will use it. ..

Best regards.

Hey, I think we already support DWAA and DWAB EXR compression? So I am a little confused about your request.

Hi, yes thats true, but, you dont brought it to the end. You implemented 50% of the DWAA and DWAB support. I can't see any Compression Rate Tab or Setting, but that is really crucial. At which Rate is your DWAA or DWAB compressing? Propper Values are between 20 and 500. A DWAA Layer is used as Compositing Layer with a Production Ready Compressing between 30 and 50. A final composed Layer will be saved with DWAB at 150.

The next important thing is, That blenders Compositor isn't able to read those files of Multilayer EXR's. In short words Blender is not able to read all Renderlayers in the Multilayer EXR DWAA/DWAB Compressed file.

So i want to help you that the responsible code designer understands that there are important missing features. The current version in 2.78c is useless in short words crap. So it would be a good idea to fix it ASAP so that larger productions can use it how it should behave in almost every other Comp/3d app.

To get it done please contact the Natron developer, he integrated it properly into Natron so hopefully he can help you. Please also read the third comment from Deke Kincaid
August 27, 2016 - 3:48 PM http://community.foundry.com/discuss/topic/125476 it will help you to understand problem.

Best Regards ;)

Note that per render layer compression can be accomplished with the file output node in the compositor.
The only thing I think that might be lacking is the ability to do this for a multilayer EXR.

Jesus Alex, you are at it again with your hyperbolic rubbish.

So it would be a good idea to fix it ASAP so that larger productions can use it how it should behave in almost every other Comp/3d app.

That's right, all of the larger productions with millions of dollars in their pipelines invested in Nuke are going to stop everything and grab Blender because now there is a compression ratio control exposed somewhere you weren't looking.

facepalm

Brecht Van Lommel (brecht) renamed this task from Important missing Feature Request for DWAA and DWAB. to OpenEXR DWA compression should not apply to non-color data passes.Apr 16 2017, 7:35 PM
Brecht Van Lommel (brecht) reopened this task as Open.
Brecht Van Lommel (brecht) triaged this task as Confirmed priority.

I agree there is a bug here, renamed the title to reflect that. I don't think we need manual control, just for some passes with vector/ID/.. types instead of color we need to tell OpenEXR not to apply lossy compression. The same goes for half float compression really, that's also not suitable for most data passes.

Ok accepted. At which rate is dwaa and dwab compressing? I asked because if you maybe scaleup the pass from 2k to 4k it would be nice when the compression rate is not above 50. Thats why i asked about a manual slider for compression. I guess if it would compress at 45 as default. all should be fine. Thanks for reactivating the issue and yeah happy easter.

Blender uses the default compression level of 45.

So OpenEXR applies lossy compression only to the following channel names: R, G, B, Y, BY, RY. The issue here is the Y channel, which can not only be luminance but also the Y in XYZ.

This appears to be hardcoded, no way to change this without editing the OpenEXR source code. The OpenEXR docs contain channel name conventions for various cases, but not for XYZ vector coordinates.

A workaround is to use lowercase xyz channel names. However Blender itself assumes upper case channel names when reading files, so needs to become case insensitive. The question is how many other applications will not be able to read such files with lower case channel channels. From a quick look Natron also seems like it assumes upper case XYZ channel names.

Perhaps the best solution here would not be to change anything in Blender, but to fix OpenEXR to only apply lossy compression to the Y channel when it is the only channel or if it goes along with BY and RY channels.

Hello, not sure where to find someone who could answer that specific question, but in Blender 2.79, OpenEXR DWAB compression has been removed, there's only DWAA left. Why is this?
Isn't DWAB supposed to be slightly better compressed and generally faster to load?

Hello, not sure where to find someone who could answer that specific question, but in Blender 2.79, OpenEXR DWAB compression has been removed, there's only DWAA left. Why is this?
Isn't DWAB supposed to be slightly better compressed and generally faster to load?

Its really missing yes. And important. A other problem with 2.79 is that Blender 2.79 on Linux is not able anymore to read EXR File textures without problems. Blender is slowing down massivly and consume almost the entire CPU when you try to read exr textures. I can confirm that this is only a problem in Blender 2.79. This also need to be fixed soon.

DWAB was disabled due to T50673.

If there is a problem reading EXR files, please report a bug with example file to reproduce, because I don't see any problems in my tests.

Thank you Brecht, I couldn't find an answer, now I have it :)
I hope this can be solved sometime down the road.
I don't have any problem on my side though, with reading and writing EXR files with Blender.