TIFF renders are limited to 8 bit even when we choose 16. #32626

New Issue

Evelyne Theodose · 2012-09-21T23:29:58+02:00

Evelyne Theodose commented

2012-09-21 23:29:58 +02:00

%%%CPU: AMD Athlon X2 2800
RAM: 4 GB
GFX: nVidia GT440 1 GB
OS: Windows 7 64
Drivers: 301.42
Blender: "2.64-RC1-windows64" --> 2.63.19 r50697%%%

%%%CPU: AMD Athlon X2 2800 RAM: 4 GB GFX: nVidia GT440 1 GB OS: Windows 7 64 Drivers: 301.42 Blender: "2.64-RC1-windows64" --> 2.63.19 r50697%%%

Evelyne Theodose commented

2012-09-21 23:29:58 +02:00

Changed status to: 'Open'

Ejner Fergo commented

2012-09-22 04:12:15 +02:00

%%%Confirmed on Linux 64bit - (BI + Cycles)

This happens when saving as RGB. Choosing RGBA saves as 16bit. %%%

%%%Confirmed on Linux 64bit - (BI + Cycles) This happens when saving as RGB. Choosing RGBA saves as 16bit. %%%

Evelyne Theodose commented

2012-09-22 17:13:16 +02:00

%%%Thanks for the tip, Ejner. Could you please share which Linux build you've been using? In Fedora 16, the RGBA render only has a 32-bit depth, so still 8 bits per channel. Does it work better in Ubuntu?%%%

Ejner Fergo commented

2012-09-22 20:52:53 +02:00

%%%Hi Evelyne,

I'm on Fedora 17, and I tested on Blender SVN (now at r50814) and 2.64-RC1.
Rendering RGBA here gives 16 bits per channel (8 bit alpha) - weird that you don't get that in F16?

I made a diff of 'tiff.c' from 2.63a & 2.64-svn and AFAICS the changes are primarily formatting, and a bit of color-management. Only place I found a bigger change is this (from line 789): http://www.pasteall.org/35473/diff
But I'm not qualified to understand what that change implies...%%%

%%%Hi Evelyne, I'm on Fedora 17, and I tested on Blender SVN (now at r50814) and 2.64-RC1. Rendering RGBA here gives 16 bits per channel (8 bit alpha) - weird that you don't get that in F16? I made a diff of 'tiff.c' from 2.63a & 2.64-svn and AFAICS the changes are primarily formatting, and a bit of color-management. Only place I found a bigger change is this (from line 789): http://www.pasteall.org/35473/diff But I'm not qualified to understand what that change implies...%%%

Evelyne Theodose commented

2012-09-22 23:08:22 +02:00

%%%Thanks for doing all this testing. In case it can help solve this mystery, here are further test results in Fedora 16 and Windows 64:

Blender 2.63a
RGBA TIFF → 64-bit color depth=16 bits per channel

Blender 2.63.20 r50741 (the most recent build you can get on GraphicAll.org)
RGBA TIFF → 32-bit color depth=8 bits per channel

Like you, I have no idea what the maths are behind the new color management feature. But the RRT and Film options look lovely, so thanks a lot, Blender devs :-) %%%

%%%Thanks for doing all this testing. In case it can help solve this mystery, here are further test results in Fedora 16 and Windows 64: Blender 2.63a RGBA TIFF → 64-bit color depth=16 bits per channel Blender 2.63.20 r50741 (the most recent build you can get on GraphicAll.org) RGBA TIFF → 32-bit color depth=8 bits per channel Like you, I have no idea what the maths are behind the new color management feature. But the RRT and Film options look lovely, so thanks a lot, Blender devs :-) %%%

Ejner Fergo commented

2012-09-23 00:25:08 +02:00

%%%Ok I didn't look carefully when checking the image info before. I was fooled by this output from ImageMagick (identify -verbose):

Depth: 8/16-bit
Channel depth:
  red: 16-bit
  green: 16-bit
  blue: 16-bit
  alpha: 8-bit

when in fact it all channels are 8 bit:

Channel statistics:
  Red:
    min: 0 (0)
    max: 255 (1)

where it should be from 0 - 65535, and same for the alpha channel.

So you are absolutely correct, both RGB and RGBA TIFFs are saved in 32 bit color depth in 2.64-RC. Sorry about that. I'll keep digging.

PS: I like your dragon :)%%%

%%%Ok I didn't look carefully when checking the image info before. I was fooled by this output from ImageMagick (identify -verbose): ``` Depth: 8/16-bit Channel depth: red: 16-bit green: 16-bit blue: 16-bit alpha: 8-bit ``` when in fact it all channels are 8 bit: ``` Channel statistics: Red: min: 0 (0) max: 255 (1) ``` where it should be from 0 - 65535, and same for the alpha channel. So you are absolutely correct, both RGB and RGBA TIFFs are saved in 32 bit color depth in 2.64-RC. Sorry about that. I'll keep digging. PS: I like your dragon :)%%%

Ejner Fergo commented

2012-09-23 00:27:23 +02:00

%%%Correction: 2.64 saves them as 8 bit, not 32 bit color depth :P%%%

Evelyne Theodose commented

2012-09-23 11:12:07 +02:00

%%%Hi Ejner,
You were right, 2.64 saves them in 32-bit color depth which means 32 bits per pixel: in each pixel, you have 8 bits for the red, blue, green and alpha channels.
The dragon is a demo file from BlenderDiplom to make sure that the bug isn't related to my experiments with OpenColorIO. You can check out their tutorial here: http://www.blenderdiplom.com/index.php/en/tutorials/item/100-blender-264-tutorial-skin-modifier
Cheers,
Ev.
%%%

%%%Hi Ejner, You were right, 2.64 saves them in 32-bit color depth which means 32 bits per pixel: in each pixel, you have 8 bits for the red, blue, green and alpha channels. The dragon is a demo file from BlenderDiplom to make sure that the bug isn't related to my experiments with OpenColorIO. You can check out their tutorial here: http://www.blenderdiplom.com/index.php/en/tutorials/item/100-blender-264-tutorial-skin-modifier Cheers, Ev. %%%

Evelyne Theodose commented

2012-09-23 22:51:43 +02:00

%%%Here's a workaround for people who might be facing the same issue:
1/ Render half-float EXRs.
2/ Use a linear to sRGB LUT. This one gives good results inside DaVinci Resolve: http://f1.creativecow.net/4336/4336
Thanks a ton, Andreas Bravin Karlsson, and thanks Ejner for taking the time to test things out. Given the number of bugs waiting, please consider this one as fixed :-)%%%

%%%Here's a workaround for people who might be facing the same issue: 1/ Render half-float EXRs. 2/ Use a linear to sRGB LUT. This one gives good results inside DaVinci Resolve: http://f1.creativecow.net/4336/4336 Thanks a ton, Andreas Bravin Karlsson, and thanks Ejner for taking the time to test things out. Given the number of bugs waiting, please consider this one as fixed :-)%%%

Campbell Barton commented

2012-09-24 03:14:51 +02:00

%%%fixed - this now works as before in 2.63, r50839.

note that the float buffer is converted from float-rec709 color into sRGB color space, without talking into account blender colorspace settings. noted as a TODO in our code.%%%

%%%fixed - this now works as before in 2.63, r50839. note that the float buffer is converted from float-rec709 color into sRGB color space, without talking into account blender colorspace settings. noted as a TODO in our code.%%%

Sergey Sharybin commented

2012-09-24 09:36:56 +02:00

%%%Re-opening, fix isn't actually correct and proper solution should be re-thinked.%%%

Evelyne Theodose commented

2012-09-24 12:39:53 +02:00

%%%Thanks for working on it, Campbell and Sergey.
Another workaround would be to render 10-bit DNxHD files. Sergey, do you think it would be possible to add an option for 10-bit encoding now that FFmpeg supports it?%%%

%%%Thanks for working on it, Campbell and Sergey. Another workaround would be to render 10-bit DNxHD files. Sergey, do you think it would be possible to add an option for 10-bit encoding now that FFmpeg supports it?%%%

Sergey Sharybin commented

2012-09-24 13:58:39 +02:00

%%%Proper fix has been commited to svn rev50843.

As for 10bit DNxHD -- of course it's possible, but that's a bit larger change and it's not going to happen for 2.64. Could look into this for 2.65.

Anyway, thanks for the report and patches, closing now. If something is still broken with image I/O please let me know :)%%%

%%%Proper fix has been commited to svn rev50843. As for 10bit DNxHD -- of course it's possible, but that's a bit larger change and it's not going to happen for 2.64. Could look into this for 2.65. Anyway, thanks for the report and patches, closing now. If something is still broken with image I/O please let me know :)%%%

Evelyne Theodose commented

2012-09-24 15:25:48 +02:00

%%%Wow, thanks a lot, that was fast...%%%

Ejner Fergo commented

2012-09-24 19:47:46 +02:00

%%%Tried to save 16 bit TIFF (RGB + RGBA) on r50852 but the result is still 8 bit images here.

After pressing F12, in the image editor I choose "Save As Image" and choose TIFF RGB 16 bit ("Save As Render" and "Copy" is on) and save. Imagemagick and Krita still reports it as 8 bit. What am I doing wrong? %%%

%%%Tried to save 16 bit TIFF (RGB + RGBA) on r50852 but the result is still 8 bit images here. After pressing F12, in the image editor I choose "Save As Image" and choose TIFF RGB 16 bit ("Save As Render" and "Copy" is on) and save. Imagemagick and Krita still reports it as 8 bit. What am I doing wrong? %%%

Sergey Sharybin commented

2012-09-24 19:53:45 +02:00

%%%Seems Save As operator is still doing something different from render result save when rendering animation. Looking again..%%%

Evelyne Theodose commented

2012-09-24 19:58:40 +02:00

%%%Hi Ejner,
It works well with animations, so in the meantime you can save an animation with only one frame. %%%

%%%Hi Ejner, It works well with animations, so in the meantime you can save an animation with only one frame. %%%

Sergey Sharybin commented

2012-09-24 20:25:02 +02:00

%%%I believe that the issue is finally fixed in svn rev50857.

Would be really appreciated if you'll test this again and let me know if some aspects of the issue are still aren't fixed :)%%%

%%%I believe that the issue is finally fixed in svn rev50857. Would be really appreciated if you'll test this again and let me know if some aspects of the issue are still aren't fixed :)%%%

Sergey Sharybin commented

2012-09-24 20:25:02 +02:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2012-09-24 20:25:02 +02:00

Ejner Fergo commented

2012-09-24 20:32:46 +02:00

%%%Yes works now :)
Thanks Sergey!%%%

%%%Yes works now :) Thanks Sergey!%%%

Evelyne Theodose commented

2012-09-24 20:38:07 +02:00

%%%Great news! The only thing special I noticed when rendering my animation was that it took a one-second delay for the viewer to adjust to the right color space. But the rendered files are perfect.%%%

Sergey Sharybin commented

2012-09-24 20:48:23 +02:00

%%%@Evelyne, not actually sure which exactly viewer you;re mentioning. Is it something to do with a compositor? Perhaps sample .blend file where the delay is noticeable would help a lot :)%%%

Evelyne Theodose commented

2012-09-24 22:01:23 +02:00

%%%Sorry, I meant the image editor that automatically replaces the 3D viewer when you choose “Animation - Display: Image Editor”.
During the first second of the animation, it looked as if the sequence editor was outputting images in the wrong color space. The first images shown in the viewer looked overexposed. But it wasn't actually the case when checking the rendered files.
Anyway, if you want, I'll try and reproduce this tomorrow when I get hold of my project files. At the moment, the available images don't show this anymore.%%%

%%%Sorry, I meant the image editor that automatically replaces the 3D viewer when you choose “Animation - Display: Image Editor”. During the first second of the animation, it looked as if the sequence editor was outputting images in the wrong color space. The first images shown in the viewer looked overexposed. But it wasn't actually the case when checking the rendered files. Anyway, if you want, I'll try and reproduce this tomorrow when I get hold of my project files. At the moment, the available images don't show this anymore.%%%

Evelyne Theodose commented

2012-09-25 10:45:17 +02:00

%%%O.K. Found a possible explanation: it came from leaving "Convert Float" checked even after there was no need to render EXR files. So maybe it's related to the new TIFF bug that Samuel has just reported.

The strange thing is that it doesn't occur every time. If you want to have a look, I've cut a really dark sample making it easy to see how overexposed it becomes.
The fastest way to reproduce this is to render animations with the same start and end frame: the render stops on a washed-out image which you can compare with the original one.

https://www.dropbox.com/sh/hjl640vu58c2lhd/-y3zwlAfK7
(the tracker system won't let me attach more files)%%%

%%%O.K. Found a possible explanation: it came from leaving "Convert Float" checked even after there was no need to render EXR files. So maybe it's related to the new TIFF bug that Samuel has just reported. The strange thing is that it doesn't occur every time. If you want to have a look, I've cut a really dark sample making it easy to see how overexposed it becomes. The fastest way to reproduce this is to render animations with the same start and end frame: the render stops on a washed-out image which you can compare with the original one. https://www.dropbox.com/sh/hjl640vu58c2lhd/-y3zwlAfK7 (the tracker system won't let me attach more files)%%%

Sergey Sharybin commented

2012-09-25 11:15:55 +02:00

%%%Confirmed the issue, looking into this. But this is something different from TIFF it seems.%%%

Sergey Sharybin commented

2012-09-25 11:35:07 +02:00

%%%@Evelyne, This issue should be fixed in svn rev50880.%%%

Evelyne Theodose commented

2012-09-25 11:41:48 +02:00

%%%Thank you again, Blender genius :-)%%%

Sergey Sharybin commented

2012-09-25 11:46:04 +02:00

%%%You're welcome :)%%%

Sign in to join this conversation.

4 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#32626

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

TIFF renders are limited to 8 bit even when we choose 16. #32626