Color pipeline bug

Project:YafaRay
Version:development
Component:Code
Category:bug report
Priority:critical
Assigned:David Bluecame
Status:closed
Description

Hi

seems that there is a serious misconfiguration in our color input pipeline in Blender. Baseline diffuse color and color mapping with a texture does not produce the same result when the same color is used for both, which is wrong. Both should produce the same result.

On the image attached, upper green is sourced from a plain sRGB #8aa08f green texture and lower green is base diffuse color using the same #8aa08f green, they should look the same. Blender color management is enabled, 2.2 gamma is used for color inputs and sRGB space color is used for texture input in texture panels. If bug is confirmed, maybe it also concerns other texture or base color inputs. It is a pity this bug has gone undetected for who knows how much time, since it has retroactive consequences for scenes configured with the bug active.

More information about render pipeline: http://www.yafaray.org/documentation/userguide/renderoutput260#outputwor...

Tested on Linux Mint 64bits

AttachmentSize
rendercolor.jpg38.51 KB

Comments

#1

Assigned to:Anonymous» David Bluecame
Status:active» needs more infos

Hello, Alvaro.

I've tried to replicate this problem but I cannot. Please will you upload your .blend file and the texture file you are using?

#2

Hi David

I have attached the blend file and texture. It also happens on Windows builds. I would like to point out that maybe texture input is well done but base color is not correctly converted into linear space.

AttachmentSize
colorbug.zip 135.78 KB

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#3

Status:needs more infos» active

Hello, Álvaro.

Thanks for the example blend and texture files, they were helpful to replicate this problem.

Yes, indeed we have a significant problem with the color pipeline in general. You already opened several issues in the bugtracker about different problems with gamma and YafaRay/Blender color space management.

In this particular case, I think part of the problem is that the Blender color picker value conversion is handled by the Blender Color Space setting, while the texture conversion is handled by YafaRay.

Moreover, the Color Space setting in the Texture tab only seems to affect the texture/material preview but it does not seem to have any effect whatsoever in the render result (handled by YafaRay). In fact, that setting apparently is not even evaluated by YafaRay code at all (??).

I have to look deeper into all this...

#4

When Blender Color Management was enabled two years ago, a full review was due and I suppose it is still missing on how YafaRay integrates into its pipeline. I hope you can look into it since is not a small issue. I suppose users are now overcompensating on their color controls to get their desired results. Thanks.

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#5

Sorry, Entry edited because an bad reference..

Greetings..

#6

Component:Blender Exporter» Code
Status:active» needs review

Hello,

While investigating this issue I think I've found even worse issues in YafaRay. There are two things that worry me:

* I believe that YafaRay is applying the Input Gamma correction to the Blender Color picker floating point values. From the tests I've done, I think the color picker floating point values are supposed to be already linear so applying the input gamma correction to them would create dark and non-linear colors in the YafaRay renders.

* For the "non-HDR" textures such as PNG, etc, YafaRay is applying the input gamma correction. However there are two problems with this:

1) YafaRay does not care about the "Color Space" setting in the Textures panel. No matter what color space you choose, it will always apply the input gamma correction to the (non-HDR) texture.

2) When using typical textures like PNG with a sRGB color space, applying the input gamma correction to the texture results in incorrect linear values. This is because sRGB is more complex than a simple gamma correction. Moreover sRGB uses fixed coefficients and exponents while the input gamma value can be changed by the user resulting in incorrect linear values from the texture.

 

Rodrigo (darktide) told me that YafaRay has already LUT (look up tables) for sRGB texture conversion. However, I cannot find them in the code and in my tests I cannot see proper sRGB texture conversions anywhere.

In any case I'm not an expert in this field, so I have prepared a test with a scene rendered in YafaRay, Blender Internals and Blender Cycles. The scene, textures and rendered results are in the attached zip file.

DESCRIPTION AND RESULTS FROM MY TESTS (see attached zip file for all the files and images)

For this test I've created a scene with these specifications:

* No lamps (to avoid discrepancies due to illumination)

* 4 planes with emission = 1.0, so they emit their surface color exactly.

* Blender output device = sRGB

* Textures color space = sRGB

* YafaRay output gamma = 1.0

* YafaRay input gamma = 2.2

Scene description.jpgScene description.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The colors and textures used for each plane are:

* World background: color picker (linear) = (0.1, 0.1, 0.1)

* Top left plane: color picker (linear) = (0.216, 0.216, 0.216)

* Top right plane: texture (PNG, sRGB) = #808080

* Bottom left plane: color picker (linear) = (0.003, 0.003, 0.003)

* Bottom right plane: texture (PNG, sRGB) = #0A0A0A

 

Acording to the sRGB conversion formulas (see https://en.wikipedia.org/wiki/SRGB#Specification_of_the_transformation):

* sRGB 0A (hex) = linear 0.003 (aprox)

* sRGB 80 (hex) = linear 0.216 (aprox)

 

So, when we render this scene, the two top planes should appear with the same (or very similar) colors. Also, the two bottom planes should appear with the same (or very similar) colors.

Blender Internal and Cycles do what I would expect, but YafaRay is not doing the same:

Blender Internal render:

rendered - gamma_sRGB_test1_Blender_Internal - (display sRGB)rendered - gamma_sRGB_test1_Blender_Internal - (display sRGB)

 

 

 

 

 

 

 

 

 

 

 

 

Cycles render:

rendered - gamma_sRGB_test1_Cycles - colors ok, preserved.pngrendered - gamma_sRGB_test1_Cycles - colors ok, preserved.png

 

 

 

 

 

 

 

 

 

 

 

 

YafaRay render. Here the objects whose color has been chosen with the color picker are much darker (even the background), and different from the objects whose color has been chosen from a texture. The color objects from textures look almost ok, but their color has not really been calculated correctly either.

rendered - gamma_sRGB_test1_YafaRay -  colors WRONG, lost.pngrendered - gamma_sRGB_test1_YafaRay - colors WRONG, lost.png

 

 

 

 

 

 

 

 

 

 

 

 

This is what I would expect:

 

TOP LEFT PLANE

* The renderer uses the (already linear) color picker floating point values (0.216, 0.216, 0.216) to create the surface color.

* As this is an emission surface with emission factor = 1.0, the camera should get exactly that color (0.216, 0.216, 0.216)

* During the Output sRGB conversion, the linear color (0.216, 0.216, 0.216) gets converted into #808080 in the rendered image being saved to a PNG file.

- Blender Internals does this correctly, the pixel values in the rendered PNG file for this plane are #808080

- Cycles does this correctly, the pixel values in the rendered PNG file for this plane are #808080

- YafaRay does this incorrectly: the pixel values in the rendered PNG file for this plane are #343434. I think this is because it's incorrectly applying the Input Gamma correction (2.2) to the color picker linear values.

 

TOP RIGHT PLANE

* The renderer uses the color from a PNG sRGB texture with values #808080 to create the surface color.

* So, it has first to “decode” the sRGB value #808080 to the linear RGB, which should be aprox. (0.216, 0.216, 0.216)

* As this is an emission surface with emission factor = 1.0, the camera should get exactly that color (0.216, 0.216, 0.216)

* During the Output sRGB conversion, the linear color (0.216, 0.216, 0.216) gets converted into #808080 in the rendered image being saved to a PNG file.

- Blender Internals does this correctly, the pixel values in the rendered PNG file for this plane are #808080

- Cycles does this correctly, the pixel values in the rendered PNG file for this plane are #808080

- YafaRay does this slightly incorrectly: the pixel values in the rendered PNG file for this plane are #818181. I think this is because it's incorrectly applying the Input Gamma correction (2.2) to the texture, when it should be applying the standard sRGB correction acording to the formulas in https://en.wikipedia.org/wiki/SRGB#Specification_of_the_transformation

 

TOP RIGHT PLANE

* The renderer uses the (already linear) color picker floating point values (0.003, 0.003, 0.003) to create the surface color.

* As this is an emission surface with emission factor = 1.0, the camera should get exactly that color (0.003, 0.003, 0.003)

* During the Output sRGB conversion, the linear color (0.003, 0.003, 0.003) gets converted into #0A0A0A in the rendered image being saved to a PNG file.

- Blender Internals does this correctly, the pixel values in the rendered PNG file for this plane are #0A0A0A

- Cycles does this correctly, the pixel values in the rendered PNG file for this plane are #0A0A0A

- YafaRay does this incorrectly: the pixel values in the rendered PNG file for this plane are #000000. I think this is because it's incorrectly applying the Input Gamma correction (2.2) to the color picker linear values.

 

TOP RIGHT PLANE

* The renderer uses the color from a PNG sRGB texture with values #808080 to create the surface color.

* So, it has first to “decode” the sRGB value #0A0A0A to the linear RGB, which should be aprox. (0.003, 0.003, 0.003)

* As this is an emission surface with emission factor = 1.0, the camera should get exactly that color (0.003, 0.003, 0.003)

* During the Output sRGB conversion, the linear color (0.003, 0.003, 0.003) gets converted into #0A0A0A in the rendered image being saved to a PNG file.

- Blender Internals does this correctly, the pixel values in the rendered PNG file for this plane are #0A0A0A

- Cycles does this correctly, the pixel values in the rendered PNG file for this plane are #0A0A0A

- YafaRay does this incorrectly: the pixel values in the rendered PNG file for this plane are #030303. I think this is because it's incorrectly applying the Input Gamma correction (2.2) to the texture, when it should be applying the standard sRGB correction acording to the formulas in https://en.wikipedia.org/wiki/SRGB#Specification_of_the_transformation

 

BACKGROUND:

The background is also darker in YafaRay because it's applying the input gamma correction to the already linear Background color picker floating point values.

 

CONCLUSION:

I'm not an expert but I can see YafaRay is doing things differently than other renderers and it seems to me that the YafaRay color pipeline is not doing the correct things.

I think we need to do this:

* Avoid applying the input gamma correction to the floating point values in the color picker, as they are supposed to be already linear.

* Implement a proper sRGB decoding for sRGB textures instead of the current “simple” input gamma correction.

 

Please let me know what you think about all this. I will try to do more tests and will upload them here as well.

AttachmentSize
gamma_sRGB_issues_scenes.zip 502.33 KB

#7

I have attached the blend files for another test, this time Blender Internal vs YafaRay.

I've used a similar sRGB / Gamma settings as in the previous test. This time the cube and sphere in the left side have a color picker Hex value #70C090 (the hex value has gamma included as opposed to the floating point color picker values).

The cube and sphere in the right side get their colors from a PNG sRGB texture with color #70C090. I also used that texture for the World background and the big plane.

This time I illuminated the scene with a sun pointing 90º vertical and strength=1.

What I would expect is to get the same colors for background, plane and top of the two cubes. Blender internal does it correctly but YafaRay does it wrong in several ways:

Blender internal render:

rendered_-_gamma_sRGB_test2_Blender_Internal_-_(displayrendered_-_gamma_sRGB_test2_Blender_Internal_-_(display

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

YafaRay render:

rendered_-_gamma_sRGB_test2_YafaRay_-__colors_WRONG.pngrendered_-_gamma_sRGB_test2_YafaRay_-__colors_WRONG.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

There are several things wrong:

* The colors chosen with the color picker (left cube and left sphere) look darker than they should (and unfortunately they are also probably non-linear!), because Blender does the sRGB conversion to the Color Picker Hex values to the linear Color Picker floating point values, and then YafaRay (incorrectly) does the input gamma conversion over the (already linear) Color Picker floating point values.

* The colors chosen from the texture for the right cube, sphere and the big plane look apparently correct. However, there is a small difference because YafaRay is using a basic (and variable) input gamma conversion to the texture while Blender Internal applies a proper sRGB decoding to the texture.

* The background color is wrong. Even when the texture used for the background is the same used for the right cube,  sphere and the big plane, the background appears brighter. I think that's because (for some weird reason) no correction at all (neither sRGB nor input gamma) is applied to this PNG sRGB background texture in YafaRay, which is also wrong in my opinion.

 

I could not test this properly in Cycles, the colors in Cycles are totally different from the results in BI and YafaRay. That could be just that Cycles handles sun light in a different way, maybe the global illumination is affecting them or even it could be some kind of bug in Cycles?  In any case in Cycles the left cube/sphere looks exactly like the right cube/sphere and the big plane as I would expect but, in principle, to avoid introducing additional confusion I have not included here my Cycles test.

I hope this second test helps clarifying the matter with colors...

AttachmentSize
gamma_sRGB_test2_Blender_Internal.blend 540.62 KB
gamma_sRGB_test2_YafaRay.blend 544.85 KB

#11

Hi David

This bug is previous to Blender Color Management implemented in Blender 2.64. It happens in Blender 2.62 and YafaRay 0.1.2

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#12

Two questions David

I wonder if the result on the left in yafaray renders is correct or is wrong.

Second, I am still really curious about what kind of result we would get if we render this in XML, but unfortunately yafaray-xml does not work neither on my linux or windows YafaRay 0.1.99 installations, do you have a working one to share?

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#13

Hello, Álvaro.

To execute yafaray-xml in Linux when using the Blender Exporter, please do this:

First check that you have the executable "yafaray-xml" in this folder:

/(path to your Blender installation)/(Blender version)/scripts/addons/yafaray/bin/

If you can see it, then you have to type this in the Terminal:

LD_LIBRARY_PATH="/(path to your Blender installation)/(Blender version)/scripts/addons/yafaray/bin/" /(path to your Blender installation)/(Blender version)/scripts/addons/yafaray/yafaray-xml  -pp "/(path to your Blender installation)/(Blender version)/scripts/addons/yafaray/bin/plugins" -f png (your filename).xml

 

For example this is the line I use to execute yafaray-xml in my system:

LD_LIBRARY_PATH="/home/david/blender64/2.76/scripts/addons/yafaray/bin/" /home/david/blender64/2.76/scripts/addons/yafaray/yafaray-xml  -pp "/home/david/blender64/2.76/scripts/addons/yafaray/bin/plugins" -f png 001.xml

Please let me know if you have any issues with it. I will try to make it easier in future releases.

#15

Hello,

I've prepared a quick YafaRay prototype that fixes the next issues:

* Fixed: Double application of input gamma to the Blender Color picker. So now scenes will look brighter in general, but they should also look more realistic with less tweaking.

* Gamma input correction no longer used. The color picker floating point color values will be considered already linear and no conversion applied to them. When using textures from non-HDR format files, a hardcoded sRGB decoding will take place.

* Gamma output correction no longer used. Instead, when saving to non-HDR file formats, a hardcoded sRGB encoding will be applied while saving the file.

* Input and Output gamma values are no longer used. I have not removed them from the UI yet, but we could.

* Fixed: when exporting to file there was an error in Blender while reopening it to be shown in the Blender image view.

 

Pending:

* Review by the developers.

* Addidional tests.

* Backwards compatibility?

* Decide how the XML color definition floating point values should be treated: as linear or as sRGB?

* Decide if to leave for now the "hardcoded" sRGB encoding/decoding or if to make ir more flexible adding additional possible Color Spaces.

 

I have attached the example Cornell Box scene from samo, rendered with the current YafaRay (wrong due to the application of gamma to the color picker) and the new YafaRay prototype (which ignores gamma and uses sRGB encoding/decoding)

 

I will prepare a build of the new prototype so you can try it. Linux 64bit is enough or do you need it for Windows as well?

Samo's CornellBox with current YafaRay (wrong).pngSamo's CornellBox with current YafaRay (wrong).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Samo's CornellBox with new YafaRay sRGB prototype.pngSamo's CornellBox with new YafaRay sRGB prototype.png

 

#16

Just out of curiosity I've rendered samo's Cornell Box with Photon Mapping and the result looks nice in the new prototype.

 

Samo's_CornellBox_(with_Photon_Mapping)_with_new_YafaRay_sRGB_prototype.pngSamo's_CornellBox_(with_Photon_Mapping)_with_new_YafaRay_sRGB_prototype.png

#17

I've updated my Core and Blender-Exporter branch "gamma_issues" with the changes I made respect to "master" for this new prototype.

[Edited 28/sept/2015: I have removed the links to avoid confusion and wasting time, as I'm starting to do it in a different way]

#18

Very interesting result, in line with what Cycles does. Testing it right now.

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#19

Backwards compatibility?

I can only speak for myself. I have dozens of scenes made with YafaRay, most of them professional work. I rarely have to get back to finished work for review or modifications, but I do it sometimes to get a material or texture I want to reuse in a new work. I don't mind losing backwards compatibilty and we have already lost it several times already, from YafRay to YafaRay and from Blender 2.49 to Blender 2.50. I suspect the bigger impact will be for people finishing a scene right now with YafaRay.

The only suggestion I have is to keep branch and binaries of current malfunctioning version for us and for people needed to review old works with a version actually compatible with it. This suggestion could be made extensible to all releases we do, as in other projects (Blender, Python, etc).

Decide how the XML color definition floating point values should be treated: as linear or as sRGB?

In my opinion, users always work in a sRGB enviroment because latest monitors are calibrated to show sRGB gamut, D65 whitepoint and 2.2 gamma. Color inputs therefore should be always treated as sRGB from users' perspective. In fact, I believe we should take not floating points values from Blender exporter color pickers but sRGB colors instead and do the conversion ourselves in core, so we make it consistent with sRGB texture input and with XML color inputs. Therefore we still need a general gamma input value for base colors.

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#20

Decide if to leave for now the "hardcoded" sRGB encoding/decoding or if to make ir more flexible adding additional possible Color Spaces.

I don't know what big studios are doing but sRGB and linear color spaces are industry wide standards ATM and will be hard to change that in the near future, at least at our professional level. Take into account that making a color space mainstream takes not only software but widespread hardware changes as well. For instance, using adobe RGB color space means that you need using ICC profiles all the time, a very expensive wide gamut monitor, a graphical card able to support it, adobe sRGB textures and finalist adobe sRGB devices like printers or projectors, a fully calibrated pipeline, etc. If someone needs that level of professionalism from YafaRay they could as well lend us a hand to implement it.

VD16 is used by OpenColorIO and CIE XYZ is for decoding and encoding ICC profiles but we are not ready for that stuff yet.

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#21

Hello,

I will try to set some color space parameters and to link them to Blender as much as I can.

On the other side, I'm reconsidering some of the changes I've made in the prototype (especially considering that I made it just as a quick proof of concept, but not as a "definitive" solution).

For example if you use sRGB textures for bump and normal mapping I'm not sure if we should decode the sRGB to lineal for the bump/normal mapping or if we should consider an sRGB texture as "sRGB" only for colors and "linear" for bump/normal mapping?  think currently YafaRay only applies input gamma when using a texture for coloring.

In any case, my next build will probably be quite different to that prototype, and hopefully more flexible and integrated with Blender, so to avoid confusion and waste of time I have removed the links and will work on a better solution.

#22

First it is important remembering that gamma correction is used in color spaces to allow for more shades in the lower part of the histogram, which is eventually how human perception works.

Scalar textures in principle should not be corrected. An scalar value of 0.20 in the sRGB space should mean 0.20 in the linear space YafaRay core works with. This way we take advantage of the richer variation of shades offered by gamma corrected color spaces such as sRGB, and take this variation directly into linear values for bump, spec reflection, etc.

However, they should be considered as sRGB in the Color Space dropdown panel since it is after all a sRGB-created texture and it does not make sense to 'look' at them as linear data. Also this way we can use the same sRGB texture for color and scalar mapping at the same time. I think now YafaRay tags them as a sRGB input but handles them accordingly once it detects it is applied to an scalar feature.

It is all about the users' sRGB enviroment perception first and the linear nature of YafaRay second.

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#23

Thank you, Álvaro. I will prepare a beta as soon as possible with all these criteria in mind.

I'm very busy in my daily work, but I will try to do something as soon as possible...

#24

hi this is a little diagram about how the color pipeline should work

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#25

Thank you, Álvaro, that's very helpful.

 

A question: do we really have to do the gamma decoding to the procedural textures or are they supposed to be linear?

Also, how should we deal with the background, for example Sky backgrounds?  DarkSky has several Color Space options...

#26

do we really have to do the gamma decoding to the procedural textures or are they supposed to be linear?

A procedural texture is just like a sRGB texture input, it is created in the user's sRGB enviroment so it should get gamma decoding when it is used to map color and/or it should be translated linearly into scalar inputs when it is used to map values such as bump amount, reflection amount, etc. Just like a sRGB texture.

how should we deal with the background, for example Sky backgrounds?  DarkSky has several Color Space options...

Sunsky backgrounds colors are the result of user inputs like turbidity, etc. But user is taking his or her decision about sunsky parameters because the previsualisation windows which is in the sRGB color space. If done correctly, the sunsky parameters feed yafaray linear core not with colors but with input values, and the linear results YafaRay calculates for background colors are sent to the previsualisation windows with gamma encoding, depending on the color space set by user. Therefore maybe sunksy models should not be on the list of color inputs. Correct me if I am wrong.

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#27

Hello,

I've made a second prototype. This time I did it in a different way. The changes are deeper and more complex but also more flexible at the same time and with better integration with Blender Color Space management.

The prototype is here, for developers testing only:

https://github.com/DavidBluecame/YafaRay---unofficial-Builds/raw/master/YafaRay%20PROTOTYPE_ColorSpaces_2015-10-03%20(DEVLOPERS%20TESTING%20ONLY)%20for%20Linux%2064bit.zip

 

The changes I propose for Core and Blender Exporter are in the next links:

https://github.com/DavidBluecame/Core/commit/5565ef646fcc513ce3f8c2842db...

https://github.com/DavidBluecame/Blender-Exporter/commit/e3cdc46e8f1a2aa...

https://github.com/DavidBluecame/Blender-Exporter/commit/0e95f2f19aa2d92...

 

List of changes:

* Improved Blender Color Space integration.
* The "simple" gamma correction has been replaced by Color Spaces:
    - LinearRGB            Linear values, no gamma correction
    - sRGB                sRGB encoding/decoding
    - XYZ                XYZ (very experimental) support
    - Raw_Manual_Gamma    Raw linear values that allow to set a simple gamma output correction manually

* Fixed: Double application of input gamma to the Blender Color picker. So now scenes will look brighter in general, but they should also look more realistic with less tweaking.
* Gamma input correction no longer used. The color picker floating point color values will be considered already linear and no conversion applied to them.
* For textures, added specific per-texture Color Space and gamma parameters.
* The color values exported to the XML file will be encoded acording to Blender Output Device Color Space setting.
* In yafaray-xml, new commandline option added: "-ics" or "--input-color-space" that allows to select how to interpret the XML color values. By default, for backwards compatibility, color values will be read as "LinearRGB", but using "-ics sRGB", the color values will be interpreted as sRGB. This setting does *not* affect the textures, as they have already per-texture specific color space/gamma parameters.
* Fixed: when exporting to file there was an error in Blender while reopening it to be shown in the Blender image view.


Pending:

* Review by the official YafaRay developers.
* Addidional tests and fine tuning.

 

A note: the Blender Color Management panel is in a different position (at the bottom of the Scene tab) when using YafaRay. That happens because I wanted to customize it to add messages and warnings for the users.

Another comment: when selecting "Render to file" you will see the Blender Display output color space (and gamma if "None" is selected) next to the output file name. I put it there for convenience, but it's exactly the same setting than you have in Scene panel - Blender Color Management.

I hope you find this interesting. Best regards!

#28

thanks David, testing right now.

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#29

Hi David

With the new color pipeline, the dynamic range of the scenes is moved to the right one stop and streched more or less 1 EV stop as well, if we use grey 18 (808080) as middle reference and the Ansel Adams Zones to work out white positions. However, the new pipeline result is still more or less correct I think though scenes will likely have relatively less range in the upper half of the histogram.

If people would like to get a scene contrast as in previous releases of YafaRay, they will likely have to shoot for a darker middle reference and acomodate sRGB texture input for that using diffuse reflection strength < 1 if needed. Camera photometers in fact are calibrated for grey 12 as middle gray, so everything is relative to that middle tone users want to set for their scenes. Also the new color pipeline will likely leave more range and variation for shadows before they become clipped, which is coincidentaly the original intent of the linear workflow. Everything is relative anyway and the important thing is that now we have a consistent pipeline to accomodate for.

YafaRay old Color Pipeline

 

YafaRay new Color Pipeline

I wish we could get input for other artists and from coders of other exporters than Blender about the new pipeline.

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#30

Everything works fine as per other questions, scalar texturing works as before and background colors are the same as before. Render times are equal.

[url=http://www.yafaray.org/community/forum/viewtopic.php?f=5&t=4986]My work[/url] · [url=http://www.yafaray.org/node/667]Grey18 workflow[/url] · [url=http://www.yafaray.org/node/760]Sampling strategy[/url]

#31

Thank you, Álvaro.

I think we have another problem, not exactly in the color pipeline but closely related to it: alpha premultiply is really not ok.

For example the output premultiplication can no longer be controlled (the option was removed some time ago) and the input textures are probably ignoring the alpha settings in the textures panel. For more info see: http://www.yafaray.org/es/node/682

I think that I should also try to fix this to get a complete solution for Color Space and Alpha, for both output and input from textures.

Any answers about the Alpha Premultiply please put them in http://www.yafaray.org/es/node/682 to keep these two issues separated in their respective case numbers.

#32

Status:needs review» ready to commit

Hello,

I've sent the following pull request to make the changes for the new Color Spaces pipeline, plus some other adjustments for Alpha Premultiply in the Exporter:

https://github.com/YafaRay/Core/pull/95

https://github.com/YafaRay/Blender-Exporter/pull/31

 

I will try to make new builds of the Experimental branch including these changes

#33

Status:ready to commit» fixed

Fixed in YafaRay-E (Experimental) v1.0.0

 

For more information, see:  http://www.yafaray.org/community/forum/viewtopic.php?f=12&t=5117

 

If you still have this issue with the new version please let us know.

#34

Status:fixed» closed

Automatically closed -- issue fixed for 2 weeks with no activity.