- User Since
- Oct 18 2011, 11:01 AM (436 w, 3 d)
Fri, Feb 7
Hi, I think it was explained that the film option is only designed to work with adjustments to the 'C' (luminance) channel.
Thu, Jan 30
I can't see how this would be classed as an improvement, feature or enhancement.
Jan 17 2020
Thanks for taking a look.
Dec 27 2019
Nov 16 2019
Thanks. I thought this could be the case but wanted to check.
Oct 31 2019
Oct 26 2019
Oct 15 2019
Sep 25 2019
Sep 15 2019
Jun 7 2019
Just to add; if as before, a solid fill object is added to a background layer - the hue is normalised.
There's now quite a hue error for semi-transparent objects:
Apr 4 2019
Just tried v1.1.1 as it was released yesterday. Unfortunately the same behaviour as 1.1.0.
Yep, I modified the bundled srgb.spi1d to match the same range as the one provided by blender_filmic and the same issue then appears. So as you say, possibly the extension at the top end of the LUT hides the issue.
Apr 1 2019
Screenshot was from me.
Mar 4 2019
Mar 2 2019
They disappeared early June 2018 which coincided with the changeover from the template_colormanaged_view_settings to template_curve_mapping widgets. The latter looks to be designed for reuse around the UI, but needs type="COLOR" to show the buttons.
Feb 14 2019
Yep, although I hesitated to say the UI colours are tied to the display device setting since they look slightly skewed;
Feb 13 2019
Jan 31 2019
Jan 28 2019
Jan 16 2019
With the viewport set to Rendered, the output still gives different results:
Oct 10 2018
@Campbell Barton (campbellbarton) I can't think of a clearer description with the current logic so the existing labels/tooltips are probably best left as-is.
Aug 26 2018
Aug 24 2018
But the first face is included in the sequence pattern, otherwise we'd see an extra selected face at the start: 1110011001100 and that isn't what's happening.
Aug 20 2018
Hi, any update on the first issue?
Aug 18 2018
Aug 16 2018
Aug 15 2018
The offset now looks OK, but the first face is still permanently selected so we get sequences like this:
Aug 14 2018
Hinting can sometimes add space between characters, but that does seem rather a lot.
Aug 13 2018
Just to recap:
It still seems that the v40 interpreter does no hinting horizontally. Since latin/western characters have a lot of straight verticals, it's an interesting design decision... Need to find out more to understand the reasoning behind this.
Aug 10 2018
Yep, that's a known tradeoff with hinted text and not really avoidable. Also the weight/boldness of the text won't be accurately represented. But you trade those things for sharp font edges. For desktop publishing, graphic design, you definitely wouldn't want it. But it's good for raw clarity (code markup, UI text, terminal/shell sessions, etc). I use both depending on the job.
Maybe I'm not reading this correctly, but in ttinterp.h from Freetype 2.9.1 on line 278:
Aug 9 2018
The change to 2.9.1 (v40) would adversely affect the font hinting.
Aug 6 2018
Aug 1 2018
Jul 28 2018
I'm unsure what the issue is.
Jul 4 2018
Sep 17 2017
Just to add:
Sep 12 2017
Sep 11 2017
I'm running Firefox dev branch (56.0b10).
Sep 8 2017
Sep 7 2017
The crux of this seems to be - "it's not a bug because the code works as intended, therefore it's a feature request" vs "the original design specification has a bug".
Sep 6 2017
Some examples drawn in the 2d editor and 3d viewport:
I can't see how this would be considered either a feature or enhancement.
Sep 3 2017
Sep 1 2017
Aug 18 2017
I can confirm this fixes the clamp function in all bevel modes except for 'percent' - in that case the bevel still sometimes stops short.
Jun 15 2017
Jun 6 2017
Jun 4 2017
May 25 2017
May 23 2017
Apr 18 2017
@Sergey Sharybin (sergey) looks like the latest linux builds are fixed.
Apr 17 2017
Confirmed. Removing the line from config.ocio is enough to fix.
Apr 16 2017
"My purpose is to enable a common/ universal audio codec by default e.g. .mp3"
Apr 15 2017
Mar 12 2017
Mar 1 2017
There seems to be two independent clamping events/rules. The 'clamp overlap' option only affects whether new bevel geometry overlaps other new bevel geometry. But even with that disabled, the bevel doesn't normally cross over pre-existing geometry (which seems sensible) - unless you're bevelling a complete edge loop.
Feb 28 2017
Looks like there's no single video format that's compatible with modern browsers...
Nov 29 2016
Is there a plan to fully define all the allowed combinations of containers, video and audio codecs, and their individual parameters? Maybe in some easily editable xml file.
Oct 11 2016
Just to add, I tried the supplied .blend and have got inconsistent results after removing the embedded images. On one attempt, RAM usage didn't decrease for the single channel image. Another attempt seemed to work.
Ah, sorry. Didn't realise the inline image was it.
Can you upload the unpacked png that's causing the problem?
I'm seeing similar behaviour on 2.78 (linux), but only for packed images. Files referenced from disk use less memory as long as they're true single channel. I'm not seeing any memory savings on GPU though - packed or unpacked.
Jun 21 2016
Jun 15 2016
It's now working as expected. Thanks for the fix!