Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [44245] trunk/blender/source/tools/ tag_release.py: script to generate commands needed to tag a release ( which has become fairly
Wow, that's awesome! Always wanted to have such king of script. Thank you!
:)
On Sun, Feb 19, 2012 at 2:39 PM, Campbell Barton ideasma...@gmail.comwrote:
Revision: 44245
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=44245
Author: campbellbarton
Date: 2012-02-19 08:39:11 + (Sun, 19 Feb 2012)
Log Message:
---
script to generate commands needed to tag a release (which has become
fairly complicated).
Example output for 2.62:
# Run these commands from the blender source dir:
svn cp https://svn.blender.org/svnroot/bf-blender/trunk@r44136
https://svn.blender.org/svnroot/bf-blender/tags/blender-2.62-release -m
tagging blender release: blender-2.62-release, 44136
svn cp https://svn.blender.org/svnroot/bf-extensions/trunk@r2994
https://svn.blender.org/svnroot/bf-extensions/tags/2_62_release -m
tagging blender release: 2_62_release, 2994
svn cp https://svn.blender.org/svnroot/bf-translations/trunk@r392
https://svn.blender.org/svnroot/bf-translations/tags/2_62_release -m
tagging blender release: 2_62_release, 392
svn sw
https://svn.blender.org/svnroot/bf-blender/tags/blender-2.62-release/blender
svn propset svn:externals addons
https://svn.blender.org/svnroot/bf-extensions/tags/2_62_release/py/scripts/addons;
release/scripts
svn propset svn:externals locale
https://svn.blender.org/svnroot/bf-translations/tags/2_62_release/locale;
release/datafiles
svn ci release/scripts release/datafiles -m tagging blender release:
blender-2.62-release, 44136
svn sw https://svn.blender.org/svnroot/bf-blender/trunk/blender
Revision Links:
--
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=44136
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=2994
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=392
Added Paths:
---
trunk/blender/source/tools/tag_release.py
Added: trunk/blender/source/tools/tag_release.py
===
--- trunk/blender/source/tools/tag_release.py
(rev 0)
+++ trunk/blender/source/tools/tag_release.py 2012-02-19 08:39:11 UTC
(rev 44245)
@@ -0,0 +1,76 @@
+#!/usr/bin/env python
+
+REV_BLENDER = 44136
+REV_EXTENSIONS = 2994
+REV_LOCALE = 392
+
+TAG_BLENDER = blender-2.62-release
+TAG_EXTENSIONS = TAG_LOCALE = 2_62_release
+
+print(\n# Run these commands from the blender source dir:)
+
+#
-
+# Blender
+
+print('svn cp '
+ 'https://svn.blender.org/svnroot/bf-blender/trunk@r%d '
+ 'https://svn.blender.org/svnroot/bf-blender/tags/%s '
+ '-m tagging blender release: %s, %d' %
+ (REV_BLENDER, TAG_BLENDER, TAG_BLENDER, REV_BLENDER))
+
+
+#
-
+# Extensions
+
+print('svn cp '
+ 'https://svn.blender.org/svnroot/bf-extensions/trunk@r%d '
+ 'https://svn.blender.org/svnroot/bf-extensions/tags/%s '
+ '-m tagging blender release: %s, %d' %
+ (REV_EXTENSIONS, TAG_EXTENSIONS, TAG_EXTENSIONS, REV_EXTENSIONS)
+ )
+
+
+#
-
+# Translations
+
+print('svn cp '
+ 'https://svn.blender.org/svnroot/bf-translations/trunk@r%d '
+ 'https://svn.blender.org/svnroot/bf-translations/tags/%s '
+ '-m tagging blender release: %s, %d' %
+ (REV_LOCALE, TAG_LOCALE, TAG_LOCALE, REV_LOCALE),
+ )
+
+
+#
-
+# Change externals
+
+# switch a checkout of trunk into the tag o avoid a second checkout
+# windows/osx may want to switch lib too.
+print('svn sw '
+ 'https://svn.blender.org/svnroot/bf-blender/tags/%s/blender' %
+ (TAG_BLENDER, )
+ )
+
+# Change the extensions location, we can ignore addons_contrib here.
+print('svn propset svn:externals '
+ 'addons
https://svn.blender.org/svnroot/bf-extensions/tags/%s/py/scripts/addons; '
+ 'release/scripts ' %
+ (TAG_EXTENSIONS, )
+ )
+
+print('svn propset svn:externals '
+ 'locale
https://svn.blender.org/svnroot/bf-translations/tags/%s/locale; '
+ 'release/datafiles' %
+ (TAG_LOCALE, )
+ )
+
+print('svn ci '
+ 'release/scripts '
+ 'release/datafiles '
+ '-m tagging blender release: %s, %d' %
+ (TAG_BLENDER, REV_BLENDER)
+ )
+
+
+# switch back to trunk
+print(svn sw https://svn.blender.org/svnroot/bf-blender/trunk/blender;)
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
--
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [44245] trunk/blender/source/tools/ tag_release.py: script to generate commands needed to tag a release ( which has become fairly
Hi,
I wonder why, but it seems the bf-translations tagging did not ran… I
had to do it (just copying above line for that repo)?
Regards,
Bastien
Le dimanche 19 février 2012 10:08:40, Sergey Sharybin a écrit :
Wow, that's awesome! Always wanted to have such king of script. Thank you!
:)
On Sun, Feb 19, 2012 at 2:39 PM, Campbell Bartonideasma...@gmail.comwrote:
Revision: 44245
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=44245
Author: campbellbarton
Date: 2012-02-19 08:39:11 + (Sun, 19 Feb 2012)
Log Message:
---
script to generate commands needed to tag a release (which has become
fairly complicated).
Example output for 2.62:
# Run these commands from the blender source dir:
svn cp https://svn.blender.org/svnroot/bf-blender/trunk@r44136
https://svn.blender.org/svnroot/bf-blender/tags/blender-2.62-release -m
tagging blender release: blender-2.62-release, 44136
svn cp https://svn.blender.org/svnroot/bf-extensions/trunk@r2994
https://svn.blender.org/svnroot/bf-extensions/tags/2_62_release -m
tagging blender release: 2_62_release, 2994
svn cp https://svn.blender.org/svnroot/bf-translations/trunk@r392
https://svn.blender.org/svnroot/bf-translations/tags/2_62_release -m
tagging blender release: 2_62_release, 392
svn sw
https://svn.blender.org/svnroot/bf-blender/tags/blender-2.62-release/blender
svn propset svn:externals addons
https://svn.blender.org/svnroot/bf-extensions/tags/2_62_release/py/scripts/addons;
release/scripts
svn propset svn:externals locale
https://svn.blender.org/svnroot/bf-translations/tags/2_62_release/locale;
release/datafiles
svn ci release/scripts release/datafiles -m tagging blender release:
blender-2.62-release, 44136
svn sw https://svn.blender.org/svnroot/bf-blender/trunk/blender
Revision Links:
--
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=44136
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=2994
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=392
Added Paths:
---
trunk/blender/source/tools/tag_release.py
Added: trunk/blender/source/tools/tag_release.py
===
--- trunk/blender/source/tools/tag_release.py
(rev 0)
+++ trunk/blender/source/tools/tag_release.py 2012-02-19 08:39:11 UTC
(rev 44245)
@@ -0,0 +1,76 @@
+#!/usr/bin/env python
+
+REV_BLENDER = 44136
+REV_EXTENSIONS = 2994
+REV_LOCALE = 392
+
+TAG_BLENDER = blender-2.62-release
+TAG_EXTENSIONS = TAG_LOCALE = 2_62_release
+
+print(\n# Run these commands from the blender source dir:)
+
+#
-
+# Blender
+
+print('svn cp '
+ 'https://svn.blender.org/svnroot/bf-blender/trunk@r%d '
+ 'https://svn.blender.org/svnroot/bf-blender/tags/%s '
+ '-m tagging blender release: %s, %d' %
+ (REV_BLENDER, TAG_BLENDER, TAG_BLENDER, REV_BLENDER))
+
+
+#
-
+# Extensions
+
+print('svn cp '
+ 'https://svn.blender.org/svnroot/bf-extensions/trunk@r%d '
+ 'https://svn.blender.org/svnroot/bf-extensions/tags/%s '
+ '-m tagging blender release: %s, %d' %
+ (REV_EXTENSIONS, TAG_EXTENSIONS, TAG_EXTENSIONS, REV_EXTENSIONS)
+ )
+
+
+#
-
+# Translations
+
+print('svn cp '
+ 'https://svn.blender.org/svnroot/bf-translations/trunk@r%d '
+ 'https://svn.blender.org/svnroot/bf-translations/tags/%s '
+ '-m tagging blender release: %s, %d' %
+ (REV_LOCALE, TAG_LOCALE, TAG_LOCALE, REV_LOCALE),
+ )
+
+
+#
-
+# Change externals
+
+# switch a checkout of trunk into the tag o avoid a second checkout
+# windows/osx may want to switch lib too.
+print('svn sw '
+ 'https://svn.blender.org/svnroot/bf-blender/tags/%s/blender' %
+ (TAG_BLENDER, )
+ )
+
+# Change the extensions location, we can ignore addons_contrib here.
+print('svn propset svn:externals '
+ 'addons
https://svn.blender.org/svnroot/bf-extensions/tags/%s/py/scripts/addons; '
+ 'release/scripts ' %
+ (TAG_EXTENSIONS, )
+ )
+
+print('svn propset svn:externals '
+ 'locale
https://svn.blender.org/svnroot/bf-translations/tags/%s/locale; '
+ 'release/datafiles' %
+ (TAG_LOCALE, )
+ )
+
+print('svn ci '
+ 'release/scripts '
+ 'release/datafiles '
+ '-m tagging blender release: %s, %d' %
+ (TAG_BLENDER, REV_BLENDER)
+ )
+
+
+# switch back to trunk
+print(svn sw https://svn.blender.org/svnroot/bf-blender/trunk/blender;)
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
Re: [Bf-committers] Color Unpremultiply
Hi, I think we can agree that if you do scene linear = sRGB conversion on the final composited image, with no alpha, that will give a correct result. It's easy to verify that if you do compositing after conversion to sRGB, it will give a different, and so a wrong result. There is one exception, and that is when you will composite over a black background. Then the associated alpha over formula becomes: (R,G,B) + (1-A)*(0, 0, 0) = (R, G, B) So, the (R,G,B) in the associated alpha image are already the same as they will be in the final composited image, and doing the conversion on either will give the same result. That's of course the exception. Now, on the web, you are commonly doing this kind of wrong compositing in sRGB space with PNG images, and it will usually not look too bad. Look e.g. here. It's not possible to know what the intended colors were here, but if you can see that composited over white/yellow the colors look a bit crappy greyish in the semi-transparent areas. http://www.w3.org/Graphics/PNG/inline-alpha-table So for me this is more a question of what the best default is, if having this enabled for premultiplied alpha images is considered better then in principle I have no problem if this gets enabled by default. However there is an extra issue which is that currently we have no way to know if the image is premultiplied or not. For render output maybe to some extent, but even then compositing can change the kind of alpha that the render has. Brecht. On Sat, Feb 18, 2012 at 7:45 PM, Troy Sobotka troy.sobo...@gmail.com wrote: I always feel like a low rent chess player speaking with a grandmaster when I am speaking with Brecht, but I believe there is some inaccurate information here. So here goes... On Feb 17, 2012 12:42 PM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: The problem is that it's not actually true that this is always the correct thing to do. [...] If you're compositing over a black background, leaving this option off will give the exact correct result. To the best of my knowledge, this statement is fundamentally incorrect. In all non-linear associated alpha (premultiplied) formats, the RGB values are in fact associating both emission / occlusion and a color component. The net sum of this is that _all_ linearizations on assocaited alpha RGB non-linear values are incorrect[1], irregardless of the background you intend to perform the over upon. Why? Because the RGB values themselves, directly out of the file, are exactly as explained above; a hybrid associated combination of occlusion / emission and RGB color. I will do my best to explain this in images if I can find some time today. As to how to determine default behavior, it is not easy because we are faced with both non-linear (EG: TIFF) and linear formats (EG: EXR) as well as the combination of associated versus unassociated alpha. The inherent nature of Blender's image loading code with correct flagging and granularity is the issue. With respect and hopefully not looking like a complete fool here, TJS [1] It should be considered more coincidence that 0.0 and 1.0 happen to be identical in pre-linearization and post-linearization, rather than any degree of overlapping logic. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developers meeting minutes, 19 February 2012
Hi all, Here's the summary of today's meeting! 1) Blender 2.62 release - Windows binary: there's a build issue, the new OpenAL lib makes 3D sound fail. Remedy: rebuild the release with original OpenAL. It will be updated on the download page with a short note then. Nathan, are you available? - Nicholas Bishop fixed a ReMesh Modifier crash on OS X PPC (endian issue) http://projects.blender.org/tracker/?func=detailatid=498aid=30158group_id=9 - Further all seems to be fine; if there's more showstoppers coming we can do an 'a' release, for now we can continue to 2.63 though. 2) Blender 2.63 plans - BMesh can go in! Brecht gave it a blessing too. (While I'm writing this, Campbell already prepares the merge. Hold tight!) - Lukas Toenne: has new File Node ready for review! http://codereview.appspot.com/5666047/ - Reminder: Lukas' Node Group project is ready too, he proposes it for 2.63 inclusion: http://codereview.appspot.com/5593050/ http://www.youtube.com/watch?v=Jk_Kk5yOYvA - Brecht and Campbell propose to make 2.63 a regular 2 month release cycle, they expect it will need this time for maturing and stabilizing. That means we can have a month for including other new features too! - BCon proposal: BCon1: 15 february BCon2: 4 march (= release targets are frozen) BCon3: 18 march (= all feature mergers were done) BCon4: 1 april (only bug fixes from now) BCon5: 8 april (ready for release) - Other 2.62 targets can be added in next 2 weeks, could be masking or other mango stuff too. - Brecht: work on Cycles during next months; mostly speedup, ramp shader and RGB curves nodes. 3_ Other projects - Ton mentions he had a meeting with Jeroen Bakker, discussing new Compositor (2.64 target) and ideas for (green screen) keying editor in Blender. Thanks, -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Do NOT commit until further notice
Hi, the B-Mesh merge to trunk is in progress, please do not commit to trunk until further notice!! Thanks! Regards, Thomas -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Raspberry Pi render farm
I think, something like HP's Project Redstone with their EnergyCards would be way more efficient if you want energy efficient rendering on ARM chips. Here's an article about them: http://www.theregister.co.uk/2011/11/01/hp_redstone_calxeda_servers/; there is also a nice article on heise for germans. Probably quite expensive, if you want to build your own renderfarm and due to their limited memory (4GB?) not too perfect for rendering complex scenes. Greetings, Markus K. Von meinem iPad gesendet Am 19.02.2012 um 12:00 schrieb bf-committers-requ...@blender.org: I was wondering if this ARM computer that can run Debian could be used to build a render farm. It only cost $35 with Ethernet, it only needs 5V and it only uses around 2 watts as far as I understand. I just guess it would need a lot less power than the PC solution at the Blender Institute right now. Getting several hundred would not be out of range and I also guess the savings in power would make up for it... anyway I'm not sure if this would be possible but I wanted to put this thought out in the open: http://www.raspberrypi.org/ For example, maybe it would be a nice side project for Mango to build a open source render farm based on Raspberry Pi... Regards, Markus Schulz ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] libredcode
Forgive me if this is the wrong mailing-list. I noticed that Camalot AV Facilties sponsored a Red Epic for the filming of Mango. So my questions are: Will libredcode be updated to support the newer firmware and .R3D codec? or Will a new library (perhaps Red's API) be integrated into blender? or Will another application be used to convert R3D files into say EXR's? or How will the RAW camera footage be used in blender? (Because it seems kind of a waste if the raw data isn't used) -NateW ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Raspberry Pi render farm
On Sat, Feb 18, 2012 at 11:27:47PM -0500, Markus Schulz wrote: I was wondering if this ARM computer that can run Debian could be used to build a render farm. It only cost $35 with Ethernet, it only needs 5V and it only uses around 2 watts as far as I understand. I'm as excited as anybody about the Raspberry Pi, but... The whole point of a renderfarm is to do work. Doing work consumes energy. Using energy consumption as a proxy for computing power, back of the envelope calculation says a multi-core Intel processor consumes ~100 watts, so 1 multi-core cpu = 50 Raspberry Pi. If you can fit 10 R-pi boards in the same case as regular cpu, you only need 5 x as much space for your farm. The cost (50 * $35 = $1750) is roughly the same as a 'regular' machine. Bottom line: I don't see any advantage. ( if your sole concern is energy consumption, I recommend getting a bunch of those hand-cranked laptops and a whole lot of orphans ) -- Stephen Swaney sswa...@centurytel.net ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Do NOT commit until further notice
SVN's open again, feel free to search code for BMESH_TODO if you have some spare time :) On Mon, Feb 20, 2012 at 5:06 AM, Thomas Dinges blen...@dingto.org wrote: Hi, the B-Mesh merge to trunk is in progress, please do not commit to trunk until further notice!! Thanks! Regards, Thomas -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] libredcode
Very interesting question! Looking forward to know more about choice on R3D files. In fact they're quite compressed and easy to use compared to EXR converted from them! --Original Message-- From: Nate Wiebe Sender: bf-committers-boun...@blender.org To: bf-committers@blender.org ReplyTo: bf-blender developers Subject: [Bf-committers] libredcode Sent: 19 Feb 2012 19:37 Forgive me if this is the wrong mailing-list. I noticed that Camalot AV Facilties sponsored a Red Epic for the filming of Mango. So my questions are: Will libredcode be updated to support the newer firmware and .R3D codec? or Will a new library (perhaps Red's API) be integrated into blender? or Will another application be used to convert R3D files into say EXR's? or How will the RAW camera footage be used in blender? (Because it seems kind of a waste if the raw data isn't used) -NateW ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers E-Mail Sent via BlackBerry from BT Mobile ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] libredcode
The SDK is obviously not even a remote option as of the suffocating distribution licensing. The rest falls under reverse engineering which, in addition to being prohibited legally as per their camera EULAs, would also be subject to a firmware change at the source that could potentially destroy all effort. On Feb 19, 2012 11:51 AM, f.paglia...@gmail.com wrote: Very interesting question! Looking forward to know more about choice on R3D files. In fact they're quite compressed and easy to use compared to EXR converted from them! There are a plethora of good reasons that the vast bulk of visual effects pipelines work off of EXR which are far too numerous to list here. R3Dcode would fail on many fronts even if it were not encumbered by restrictive licensing and lack of specification. If I were to wager, the official software will be used to generate the offline proxies and then again to pull the EXRs for online. Just a hunch. ;) With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Do NOT commit until further notice
Am 19.02.2012 20:49, schrieb Campbell Barton: SVN's open again, feel free to search code for BMESH_TODO if you have some spare time :) On Mon, Feb 20, 2012 at 5:06 AM, Thomas Dingesblen...@dingto.org wrote: Hi, the B-Mesh merge to trunk is in progress, please do not commit to trunk until further notice!! Thanks! Regards, Thomas -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers Is scons build system supposed to work ? Well it does not for me .. neither WIN nor LUNIX Grumpy ole bjornmose ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Do NOT commit until further notice
Yes, it is. There is an error atm in stubs.c, disable the GameEngine and Player and it should build fine. Am 20.02.2012 00:05, schrieb bjornm...@gmx.net: Is scons build system supposed to work ? Well it does not for me .. neither WIN nor LUNIX Grumpy ole bjornmose ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [44256] trunk/blender: BMesh Merge
Congratulations for this milestone! Especially Geoff - it's been what, 4? 5? years in the making? :) On Sun, Feb 19, 2012 at 7:12 PM, Campbell Barton ideasma...@gmail.com wrote: this is the work of quite a few developers over the years. Key Contributors * Geoffrey Bantle (aka) Briggs, original author. * Joe Eager (aka) joeedh More recently * Howard Trickey * Ender79 aka Ender79 :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Do NOT commit until further notice
That is not exactly my definition of working out of the box .. well guess give it a try with bf_withgameengine=0 bf_withplayer=0 or search the correct syntax for both grumble Am 20.02.2012 00:07, schrieb Thomas Dinges: Yes, it is. There is an error atm in stubs.c, disable the GameEngine and Player and it should build fine. Am 20.02.2012 00:05, schrieb bjornm...@gmx.net: Is scons build system supposed to work ? Well it does not for me .. neither WIN nor LUNIX Grumpy ole bjornmose ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Do NOT commit until further notice
made some minor edits and the player builds for me - r44271. On Mon, Feb 20, 2012 at 10:27 AM, bjornm...@gmx.net bjornm...@gmx.net wrote: That is not exactly my definition of working out of the box .. well guess give it a try with bf_withgameengine=0 bf_withplayer=0 or search the correct syntax for both grumble Am 20.02.2012 00:07, schrieb Thomas Dinges: Yes, it is. There is an error atm in stubs.c, disable the GameEngine and Player and it should build fine. Am 20.02.2012 00:05, schrieb bjornm...@gmx.net: Is scons build system supposed to work ? Well it does not for me .. neither WIN nor LUNIX Grumpy ole bjornmose ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Unpremultiply
On Fri, Feb 17, 2012 at 8:04 PM, gespert...@gmail.com gespert...@gmail.com wrote: First of all, the text in the tooltip is a little bit misleading. The operation performed isn't done to avoid a fringe on light backgrounds. It's done because colorspace conversions shouldn't be performed on premultiplied data. The resulting effect when doing it wrong is indeed a fringe, but what the operation does is to deliver a properly converted image, not avoiding a fringe. This may sound silly, but I think that using a more accurate tooltip would have an educational effect because people would know what it does or would investigate more rather than this is for reducing a fringe. A fringe can come from a wrong compositing earlier, and believing that color unpremultiply will fix it is wrong. +1, correct Apart from that, I wonder if it's really necessary to have that option instead of just applying it whenever premultiplied alpha is selected and the output file is gamma-corrected. Eh? I presume you're talking about the render option that does this at the end of the pipeline before saving imagery out of the renderer/compositor, and not the option per image that does this when loading the image, right? The Sky/Premul/Straight options are purely blender internal renderer things, they don't have any bearing on what comes out of the compositor. You can un-premultiply a transparent image in the compositor and pipe it straight to the output if you like, and while it will look bad in the viewer, it is a valid thing to do if you really want to. In this case, you don't want another divide before colour space conversion and need the option, no matter what sky/premul/straight option is set for BI. For situations where you're just rendering through BI straight to disk with no compositor, and the system knows it's Premul, you may have a point. But afaics that's not how this option works - it's a bit misleading having this option in the shading panel, which is full of BI related properties, since this is something that happens at the end of blender's entire imaging pipeline. If you want to make things clearer, perhaps the option should be on the compositor output node itself, and when you're not using the compositor, rendering straight out of BI, it could just do the right thing automatically since it has all the information to make that decision itself. Much of a muchness really, though... ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Unpremultiply
2012/2/19 Brecht Van Lommel brechtvanlom...@pandora.be Hi, I think we can agree that if you do scene linear = sRGB conversion on the final composited image, with no alpha, that will give a correct result. Agreed. It's easy to verify that if you do compositing after conversion to sRGB, it will give a different, and so a wrong result. Well, not necessarily. It's true that alpha-over should be done in linear space, but applications still allow to open non-linear RGBA files (both premultiplied and straight). As you mentioned, web browsers do alpha blending in sRGB space, GIMP does it too (questionable or not, it does it), and Photoshop lets you choose gamma for alpha compositing. Anyway, I agree that those images should be linearized back for a proper alpha blending if it was the point. Question is how to deal with associated alpha in that stage. There is one exception, and that is when you will composite over a black background. Then the associated alpha over formula becomes: (R,G,B) + (1-A)*(0, 0, 0) = (R, G, B) So, the (R,G,B) in the associated alpha image are already the same as they will be in the final composited image, and doing the conversion on either will give the same result. That's of course the exception. Please correct me if I missed something and I didn't get you point, but I think this is wrong. In an associated image, RGB in linear space has a correlation with alpha, which is also in linear space. so a red pixel with 50% transparency would be in rgba: 0.5,0.0,0.0,0.5 (which is, as you mentioned, the same that compositing that pixel on black). Dividing that by alpha will give a solid red pixel. If you convert that linear RGB to sRGB and alpha remains untouched (it has to), that correlation is broken. You can't get a clean red pixel dividing the alpha, it will still be contaminated. That's what Blender has been doing with premultiplied images saved in non-linear formats until color unpremul was implemented. The problem wasn't visible in Blender's compositor because when you opened back those images, they were linearized without pre-dividing alpha, so the problem was cancelled. But other applications (at least the ones I tried) seem to expect that correlation with alpha in sRGB. So for me this is more a question of what the best default is, if having this enabled for premultiplied alpha images is considered better then in principle I have no problem if this gets enabled by default. However there is an extra issue which is that currently we have no way to know if the image is premultiplied or not. For render output maybe to some extent, but even then compositing can change the kind of alpha that the render has. Hmm. This is definitely a good point. Making color unpremultiply default for premultiplied renders would be problematic if the user already divided alpha because s/he wants to save an unassociated image (a proper PNG for instance). However, I still wonder if that checkbox doesn't belong to the compositing node instead of the shading panel. Placing it in the shading panel implies that the user already planned if the output will be associated or unassociated. Placing that checkbox in the composite node and enabling it as default when premultiplied rendering is selected would make sense and would be more discoverable during compositing and therefor harder to miss. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Unpremultiply
On Sun, Feb 19, 2012 at 4:15 PM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: So for me this is more a question of what the best default is, if having this enabled for premultiplied alpha images is considered better then in principle I have no problem if this gets enabled by default. However there is an extra issue which is that currently we have no way to know if the image is premultiplied or not. For render output maybe to some extent, but even then compositing can change the kind of alpha that the render has. Well, the image viewer kind of 'implies' that output images should be premultiplied (otherwise they'll look bad), but this is probably also the fault of there being no option to choose how to interpret imagery that you're viewing, to correct accordingly. Even so, it would make sense to me that the output option would be aligned with whatever the viewer does (by default at least), so that if the viewer assumes premultiplied images by default (which in turn encourages artists to premultiply their imagery so it looks correct in the viewer) then it may be a good assumption that the output is premultiplied too, and divide accordingly. This is just talking defaults though - the option is still required. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Unpremultiply
Matt Ebb wrote: Eh? I presume you're talking about the render option that does this at the end of the pipeline before saving imagery out of the renderer/compositor, and not the option per image that does this when loading the image, right? My bad. It was the only place I could find that made as much sense from a global perspective. It _really_ belongs in the output panel. I suppose I should patch this. Erf. For situations where you're just rendering through BI straight to disk with no compositor, and the system knows it's Premul, you may have a point. But afaics that's not how this option works - it's a bit misleading having this option in the shading panel, which is full of BI related properties, since this is something that happens at the end of blender's entire imaging pipeline. If you want to make things clearer, perhaps the option should be on the compositor output node itself, and when you're not using the compositor, rendering straight out of BI, it could just do the right thing automatically since it has all the information to make that decision itself. Much of a muchness really, though... Gespertino wrote: However, I still wonder if that checkbox doesn't belong to the compositing node instead of the shading panel. Yes. Yes. Yes. Completely agree. It's my fault! I did _try_ to get the blasted thing on the output node, but the UI goes fuzzy on some of those special nodes, of which the output is one. If anyone wants to step up and demo how to put interface elements on it, I'd love it. Matt Ebb wrote: Well, the image viewer kind of 'implies' that output images should be premultiplied (otherwise they'll look bad), but this is probably also the fault of there being no option to choose how to interpret imagery that you're viewing, to correct accordingly. I really would love to see the patch[1] for toggling associated versus unassociated view committed to trunk on this note. I think it is poor form to provide a default view that doesn't accurately depict the internal alpha state, but alas... With respect, TJS [1] http://projects.blender.org/tracker/?func=detailatid=127aid=28782group_id=9 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Unpremultiply
2012/2/19 Matt Ebb m...@mke3.net Apart from that, I wonder if it's really necessary to have that option instead of just applying it whenever premultiplied alpha is selected and the output file is gamma-corrected. Eh? I presume you're talking about the render option that does this at the end of the pipeline before saving imagery out of the renderer/compositor, and not the option per image that does this when loading the image, right? I was talking about the render option, yes. I can't see that option in the other end :) I see I was wrong when I suggested that the option should be removed. It has to be there, but as I mentioned in my previous message, I think it would make more sense if that option is in the composite node and not in the rendering panel. Maybe I came to that (wrong) idea because I associated inconsciously the rendering setting with the output from seeing that option there. :-p The Sky/Premul/Straight options are purely blender internal renderer things, they don't have any bearing on what comes out of the compositor. You can un-premultiply a transparent image in the compositor and pipe it straight to the output if you like, and while it will look bad in the viewer, it is a valid thing to do if you really want to. In this case, you don't want another divide before colour space conversion and need the option, no matter what sky/premul/straight option is set for BI. Yes, I know. I do divide premultiplied composites when I need to save proper PNGs out from blender composites, so I can see what you mean. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Unpremultiply
On Mon, Feb 20, 2012 at 2:07 AM, Troy Sobotka troy.sobo...@gmail.com wrote: Yes. Yes. Yes. Completely agree. It's my fault! I did _try_ to get the blasted thing on the output node, but the UI goes fuzzy on some of those special nodes, of which the output is one. There, there :) The Colour Management option doesn't really belong there either, but it's there since half of what was involved in that work was linearising inputs to BI, and it was added before Blender really started to open up to the prospect of seamlessly using external renderers through the render API, and well before it shipped with two renderers by default. In the future, if people will be working on further implementations of this sort of thing (using a CMS for example), it would be good to keep in mind the question of how to present an accurate impression of how all this fits together in blender. At the least, a first step would be clearly separating the options concerning how colour/imagery is imported into any particular renderer (which should be handled in the properties owned by that renderer itself) vs what's going on in the rest of the pipeline surrounding that (eg. comp and file output). Right now, the distinction between BI render and comp settings is still a bit murky (eg. the sky/premul/straight option), and it needs a bit of a push into a renderer-agnostic future. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
