Values in depth channel saved incorrectly on .blend file re-open #43180

New Issue

BCheatham · 2015-01-09T15:29:37+01:00

BCheatham commented

2015-01-09 15:29:37 +01:00

System Information
OSX 10.9.5
NVIDIA GeForce GT 330M

Blender Version
Broken: 2.72b 93963ae
Worked: 2.69

Short description of error
Using compositor to save Z-channel to a greyscale png. On first creation, compositor saves images with correct depth in blender units. Then .blend file is saved and re-opened and rendering re-run in the the same way. The depths saved to the png on this second run are now incorrect (they appear to now have gamma correction applied to them).

Exact steps for others to reproduce the error

Open attached blend file
Observe that camera is 0.5 units from the plane
Delete the file output node from the compositor and re-create a file output node with these properties:
- 8-bit png
- BW
Run render
Open saved png file (/tmp/Image0001.png) in matlab/python or similar. Values should be 128 (= 0.5 * 2^8)
Save blend file and re-open
Re-render scene and open png file in matlab/python or similar. Values should be 188 (~= 0.5^(1/2.2) * 2^8)

.bug.blend

**System Information** OSX 10.9.5 NVIDIA GeForce GT 330M **Blender Version** Broken: 2.72b 93963ae Worked: 2.69 **Short description of error** Using compositor to save Z-channel to a greyscale png. On first creation, compositor saves images with correct depth in blender units. Then .blend file is saved and re-opened and rendering re-run in the the same way. The depths saved to the png on this second run are now incorrect (they appear to now have gamma correction applied to them). **Exact steps for others to reproduce the error** 1) Open attached blend file 2) Observe that camera is 0.5 units from the plane 3) Delete the file output node from the compositor and re-create a file output node with these properties: - 8-bit png - BW 4) Run render 5) Open saved png file (/tmp/Image0001.png) in matlab/python or similar. Values should be 128 (= 0.5 * 2^8) 6) Save blend file and re-open 7) Re-render scene and open png file in matlab/python or similar. Values should be 188 (~= 0.5^(1/2.2) * 2^8) .[bug.blend](https://archive.blender.org/developer/F136416/bug.blend)

BCheatham commented

2015-01-09 15:29:37 +01:00

Changed status to: 'Open'

BCheatham commented

2015-01-09 15:29:37 +01:00

Added subscriber: @BillCheatham

Bastien Montagne commented

2015-01-09 15:47:02 +01:00

Added subscribers: @Sergey, @mont29

Bastien Montagne commented

2015-01-09 15:47:02 +01:00

Sergey, do you think some colormanagement could happen here?

Lukas Tönne was assigned by Sergey Sharybin

2015-01-13 10:48:25 +01:00

Sergey Sharybin commented

2015-01-13 10:48:25 +01:00

The issue is caused by 1687023. FOr some reason after that commit socket type of the File Output node is no longer valid after file re-open (it's COLOR instead of VECTOR).

Will let author of that commit to fix the issue!

The issue is caused by 1687023. FOr some reason after that commit socket type of the File Output node is no longer valid after file re-open (it's COLOR instead of VECTOR). Will let author of that commit to fix the issue!

Joey Ferwerda commented

2017-02-09 17:43:34 +01:00

Added subscriber: @TheOnlyJoey

Joey Ferwerda commented

2017-02-09 17:43:34 +01:00

Is this still a issue?
I have tried checking the values of the rendered png's and they seem to be identical throughout renders.

Is this still a issue? I have tried checking the values of the rendered png's and they seem to be identical throughout renders.

BCheatham commented

2019-01-04 12:45:26 +01:00

It seems that several years later this is unfortunately still an issue. I can follow my steps above using 2.79b, on OSX, and reproduce exactly the same bug. I don't know where to start to try to fix this, but it would help a lot of problems we are having at this end.

@TheOnlyJoey when it worked for you, were you following the 7 steps in the bug report?

Thanks

It seems that several years later this is unfortunately still an issue. I can follow my steps above using 2.79b, on OSX, and reproduce exactly the same bug. I don't know where to start to try to fix this, but it would help a lot of problems we are having at this end. @TheOnlyJoey when it worked for you, were you following the 7 steps in the bug report? Thanks

BCheatham commented

2019-01-04 16:28:52 +01:00

Is there perhaps a workaround we could use for now? For example, is there a node I could insert before the File Output node which would force the socket type to VECTOR? Thanks.

Lukas Tönne was unassigned by Dalai Felinto

2019-12-23 16:37:55 +01:00

Germano Cavalcante commented

2020-01-16 02:46:44 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-01-16 02:46:44 +01:00

Problem still seen in blender 2.83.

Manuel Castilla commented

2020-12-25 19:13:31 +01:00

Added subscriber: @manzanilla

Manuel Castilla commented

2020-12-25 19:13:31 +01:00

Re-render scene and open png file in matlab/python or similar. Values should be 188 (~= 0.5^(1/2.2) * 2^8)

This step means we were getting 188 result and it should not happen right?

I tried the steps on "2.92.0 Alpha, branch: master, commit date: 2020-12-25 00:41, hash: 565ea3df60" - Windows 10
On step 5: I get an image with values 128
On step 7: I get an image with values 128 too

I think the results are correct. Otherwise there is something I don't understand. When connecting the depth socket to the file output node socket, the later gets converted to VALUE type. On saving and reopening is still VALUE type which I think is correct. Maybe there has been changes in later versions or it's something specific to file saving in OSX.

> 7. Re-render scene and open png file in matlab/python or similar. Values should be 188 (~= 0.5^(1/2.2) * 2^8) This step means we were getting 188 result and it should not happen right? I tried the steps on "2.92.0 Alpha, branch: master, commit date: 2020-12-25 00:41, hash: `565ea3df60`" - Windows 10 On step 5: I get an image with values 128 On step 7: I get an image with values 128 too I think the results are correct. Otherwise there is something I don't understand. When connecting the depth socket to the file output node socket, the later gets converted to VALUE type. On saving and reopening is still VALUE type which I think is correct. Maybe there has been changes in later versions or it's something specific to file saving in OSX.

Evan Wilson commented

2020-12-26 20:23:47 +01:00

Added subscriber: @EAW

Evan Wilson commented

2020-12-26 20:23:47 +01:00

While I can confirm that I can reproduce this issue in 2.79b, I do not get the issue when using 2.83 or 2.92 date: 2020-12-24 19:11, hash: af316d2761

Tested using:
OS: Windows-10-10.0.19041.630-SP0 64 Bits
GPU: GeForce GTX 470/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 391.35
CPU: i7-950 @3.07 GHz SSE2 SSE3 SSE41
RAM: 8.00 GB

While I can confirm that I can reproduce this issue in 2.79b, I do not get the issue when using 2.83 or 2.92 date: 2020-12-24 19:11, hash: af316d276144 --- Tested using: OS: Windows-10-10.0.19041.630-SP0 64 Bits GPU: GeForce GTX 470/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 391.35 CPU: i7-950 @3.07 GHz SSE2 SSE3 SSE41 RAM: 8.00 GB

Manuel Castilla commented

2021-10-23 21:38:22 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Manuel Castilla closed this issue

2021-10-23 21:38:22 +02:00

Manuel Castilla self-assigned this 2021-10-23 21:38:22 +02:00

Manuel Castilla commented

2021-10-23 21:38:22 +02:00

Seems fixed. It cannot be reproduced in newer versions.

BCheatham commented

2021-10-25 10:29:25 +02:00

Hi all – As the person who originally reported this bug, I'd just like to thank you all for carefully caring for and resolving this issue over the last few years! It's great to see a community care so much about what it builds.

Blender is often used in the computer vision community for creating datasets with ground-truth depths (e.g. http://www.tobias-weis.de/groundtruth-data-for-computer-vision-with-blender/), and this fix will ensure those saved depth values are correct.

Thanks again

Hi all – As the person who originally reported this bug, I'd just like to thank you all for carefully caring for and resolving this issue over the last few years! It's great to see a community care so much about what it builds. Blender is often used in the computer vision community for creating datasets with ground-truth depths (e.g. http://www.tobias-weis.de/groundtruth-data-for-computer-vision-with-blender/), and this fix will ensure those saved depth values are correct. Thanks again

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Values in depth channel saved incorrectly on .blend file re-open #43180