By design.
Only a hobby grade system will attempt to convert for you.
In general, most will control their content and not rely on a single
pipeline tool to prepare it for uptake.
On Oct 20, 2010 8:19 AM, Vilem Novak pildano...@post.cz wrote:
Hello,
I want ask one question.
If I load movie
I think Roger summed it up best.
Remember that in the vast bulk of professional and semi-professional /
independent motion picture production you are shooting for a fixed target.
All of your footage is consistent.
In a conversion, we begin to get into countless complexities. Duplicate
frames?
Beyond great. Can we see this pushed so that it can get solkd testing?
Brilliant work Matt. I would be interested to see what the original sensor
size was set to prior to your patch.
Wonderful.
On Oct 28, 2010 12:24 PM, Paolo Ciccone phcicc...@gmail.com wrote:
Absolutely great! Thanks for this
On Sat, Oct 30, 2010 at 9:17 AM, Dave Plater dpla...@webafrica.org.za wrote:
On 10/30/2010 04:42 PM, jmso...@free.fr wrote:
Selon Dave Plater dpla...@webafrica.org.za:
Resizing maximizing or minimizing doesn't have any effect. All I have is
the center display and the right hand side controls
A plain and simple misconception stemming from misunderstanding.
Matt summed it up perfectly in apples to oranges.
Color spaces and color models are two of the most confused areas in visual
art and design.
Values mean nothing unto themselves until we apply a colour space in a
colour model.
Don't forget that all of your work will be color clamped / matrixed if you
encode directly using ffmpeg.
Such is the nature of RGB to YCbCr / YUV transforms via ffmpeg's swscale.
If you seek quality, your only recourse is to oversee the transforms from
RGB to YUV or YCbCr yourself.
Sincerely,
I just finished reading Pablo's post over at the Sintel blog
(http://www.sintel.org/news/sintel-the-4k-experience/) and I have been
wondering if there has been any progress on the tiled rendering for
the compositor?
As someone that uses the compositor heavily, I am wondering if there
is anything
On Thu, Dec 16, 2010 at 11:31 AM, Vilem Novak pildano...@post.cz wrote:
Hello,
I put together a proposal for some further possible changes in the 2.5x UI.
I cannot comment on some of the more modelling centric elements, as I
don't have much experience with them to comment. Specifically
Would it be possible to display the color wheels correctly ? I actually
don't know if there is a correct or wrong way, I guess not, but to me it is
upside down.
Which one is correct?
http://www.willrosecrans.com/blog/2010/09/color-wheels/
___
Look at Blender ones, the red is at the bottom, while all in that page
put it at the top or the right side, following typical starts for
clocks or angles (resp.). That is what he is pointing, that Blender is
yet another style with hard to explain 0 points down.
As opposed to 0 being lower
On Fri, Jan 21, 2011 at 8:29 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Automatic data conversion between nodes. What I'm not sure about is
the different color data types (RGBA, HSVA, YUVA, ..). This would no
be exposed to the user, all they would know is that it's a Color,
right?
C) And under the Encoding panel we have real fun:
Here we have Presets dropdown that always says Presets and you never
now witch preset is active. Not only that, here we have presets that
are changing not only Encoding settings but they are also changing
dimensions of movie.
Could anyone interested in this topic please test this patch I've written?
http://projects.blender.org/tracker/?func=detailaid=25777group_id=9atid=127
It addresses the dropdown needs. The next step would be to make the
frame rate advanced options hidden and expose upon the selection of a
Custom
Summary: This patch provides an audience specific minor modification
to the user interface. For most audiences familiar with frame rates,
Blender's representation can be potentially confusing. This patch
provides seven default presets and hides the complexity of the
fps_base and fps values in the
Accordion on pointer proximity?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
On May 6, 2012 5:43 AM, Jeroen Bakker j.bak...@atmind.nl wrote:
I would like to know if the we should retain the old algorithm, only use
the tiles algorithm, or make a selection between the two algorithms.
+1 for selecting algorithms akin to the Transform node.
With respect,
TJS
On May 14, 2012 4:37 AM, Tobias Oelgarte
tobias.oelgartetobias.oelga...@googlemail.com
@
tobias.oelga...@googlemail.comgooglemail.comtobias.oelga...@googlemail.com
wrote:
This is partially wrong, since for masking you need sRGB values within
the range of 0-1.
There are two assumptions here.
On Sun, Jun 17, 2012 at 10:20 AM, Tobias Oelgarte
tobias.oelga...@googlemail.com wrote:
Are there any plans to fix the various color management issues that
exist for over a year now?
Proper color management via OCIO will alleviate many, if not all, of
the issues you have reported.
Examples:
On Jun 17, 2012 3:04 PM, Tobias Oelgarte tobias.oelga...@googlemail.com
wrote:
One general issue that i have at the moment is that there is no clean
line between images with color data and images which represent absolute
data. Bumpmaps, Normalmaps, Alpha and Masks should be linear
In the
On Jun 22, 2012 10:34 AM, Campbell Barton ideasma...@gmail.com wrote:
Does anyone know why there are 2 different color - grey-scale
conversions in blenders code?
float rgb_to_bw(const float rgb[3])
{
return 0.35f * rgb[0] + 0.45f * rgb[1] + 0.2f * rgb[2];
}
float
On Jun 22, 2012 11:56 AM, CoDEmanX codemanx
codem...@gmx.de@codem...@gmx.de
gmx.de codem...@gmx.de wrote:
but correct seems to be:
Y = 0.2126 R + 0.7152 G + 0.0722 B
Again, there is no singular correct.
I believe the above is a luminance based conversion from linearized sRGB.
With respect,
On Jun 23, 2012 5:01 AM, Campbell Barton ideasma...@gmail.com wrote:
- Texture and shading pipeline use rgb_to_bw() which treat RGB more
evenly which might be better for shading when very un-even influences
for RGB channels could be problematic for shading with textures of
different colors
On Sun, Jul 22, 2012 at 9:50 AM, Campbell Barton ideasma...@gmail.com wrote:
* shift click to drag out feather points can be kept (this means shift
for subtle movement - realize this conflicts with shift for 1/10th
motion).
Is it possible to negotiate this and keep the Blender-wide consistency
In the interest of trying to get a decent starting point of LUTs
together, I thought I'd throw out the question as to what basic LUTs
should Blender support out of the default configuration?
We should probably consider the historical Blender legacy here and
provide a most minimal transition for
Now that OCIO has begun to land in Blender, I thought it might be
worth evaluating whether we could improve the curves control in the
compositor a little.
Currently, curves operates on data between output referred values 0 and 1.
With native scene referred values, 1.0 is effectively meaningless.
It appears that something internally is a little wonk in the color
management system.
When loading the OpenColorIO test images such as Marci.png, the
transforms do not yield a 1:1 sRGB transform.
I've tested using ExponentTransforms as well, and no matter what
config (including the Nuke
On Tue, Sep 25, 2012 at 5:47 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
I've changed the
configuration file now to be a bit more clear and avoid this
intermediate step, but it should have no influence on the end result.
Odd.
I SVN upped and the issue is gone now.
Nice work on
If you turn clipping off now on RGB curves, and change Max X to a 1.0
value, you can't slide the point past 1.0
50383 is the breakage point.
Looks like the following commit broke the clipping of curve windows:
r50383 |
The topic of this thread comes up at least once per year. Please use
Google as there is a vast body of information gathered from
tremendously respectable parties, including key developer opinions and
insight.
Technical hurdles are an obvious issue. Mr. Barton cites the library
issue but also the
Is there any chance that the registering the new nodes goes through some old
system of nodes? I can now compile without any errors however(maybe
naturally) my node does not show up in the nodes in Blender. So I am
suspecting that I am not able to register this new node in the system
properly.
Campbell Barton:
Theres an inconsistency I noticed yesterday maybe someone here knows
whats going on...
While on this subject, I noticed a while back that there are a few
neareast typos littered throughout the code, where the author
clearly intended nearest referencing nearest neighbour or the
On Thu, Dec 20, 2012 at 10:36 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Premul for float and key for byte images could work.
Just in the interest of consistency, if we are going with
Premultiplied naming convention, can we roll with the inverse of
Unpremultiplied and apply it
On Thu, Dec 20, 2012 at 11:52 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
I like the names associated and unassociated because they don't
describe how you arrived at the color, just the way it is stored.
Agree 110%. It also eliminates the rather erroneous assumption that
On Thu, Dec 20, 2012 at 1:21 PM, Bartek Skorupa (priv)
bartekskor...@bartekskorupa.com wrote:
Straight and Premultiplied are the ones that most of the users know and
are used to.
We can agree that most is a speculation?
Unpremultiply sounds to me like saying unpush instead of pull.
It
On Jan 11, 2013 7:27 AM, Bartek Skorupa (priv)
bartekskor...@bartekskorupa.com wrote:
R = (1-C) * L + C
I don't believe this would work well at all with scene referred models /
spaces, of which Blender is.
Perhaps it is wiser to shift the default operation to ASC CDL format?
With respect,
On Jan 11, 2013 10:31 AM, Bartek Skorupa (priv)
bartekskor...@bartekskorupa.com wrote:
I'd prefer it working like LIFT/GAMMA/GAIN does, but this is my personal
taste.
You missed my point.
The formula does not work on scene referred data.
With respect,
TJS
On Sun, Jan 13, 2013 at 3:57 PM, François T. francoistarl...@gmail.com wrote:
but you have to know that Color Balance does a
sRGB conversion internally. I don't think it would be good to do the same
in CC
This is unfortunate. I suspect this should be reported as a bug now
that we have a proper
On Mon, Jan 14, 2013 at 7:21 AM, Bartek Skorupa (priv)
bartekskor...@bartekskorupa.com wrote:
Conversion to sRBG inside the algorithm can be treated as one of the
operations this node performs.
If we don't call this conversion to sRGB, but primary adjustment or
whatever else - we don't
On Jan 27, 2013 6:24 PM, Campbell Barton ideasma...@gmail.com wrote:
but Im
not sure about demosaicing, if its just some automatic calculation on
load -
It isn't. There is much more complexity that would also need to be
unchained from a raw image.
If we were to attempt and add a Variable
I thought I'd crawl into the code for the Gamma toggle in the Blur
node now that we have a proper color management system in place.
CODE
float inputColor[4];
this-m_inputProgram-read(inputColor, x, y, sampler);
if (inputColor[3] 0.0f) {
inputColor[0] /= inputColor[3];
inputColor[1] /=
Canal the backdrop.
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
On Mar 12, 2013 3:27 PM, Julien Enche julien.en...@gmail.com wrote:
1) At the moment, the IB_test flag is not taken in account in the
imb_load_dpx_cineon function, so color conversion happens twice. I
haven't really find out what should be done and what can be skipped when
this flag is set.
On Mar 12, 2013 10:36 PM, Sergey Sharybin sergey@gmail.com wrote:
If the question is more about 'if we could use ocio instead of hardcoded
conversions -- yes we could. If we shall -- no idea, depends on what's
exactly going on there.
This.
With respect,
TJS
Is there a reason that the color management transforms do not work on EXR
files saves?
Seems broken.
With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
On Jul 7, 2013 11:50 PM, Sergey Sharybin sergey@gmail.com wrote:
Adding a way to save in different color space is in
TODO list.
Would it not be the equivalent as to all of the other formats?
If we use the View as Render option on a JPEG for example, it applies.
On an EXR, it doesn't.
Is
On Jul 9, 2013 5:48 AM, François T. francoistarl...@gmail.com wrote:
Troy, I'm not quite sure to understand what you are asking. You would like
the color transform baked-in EXR ? IMO, exr should always be linear,
especially if you have to move it around other parts of a pipeline. The
ability
On Jul 9, 2013 8:23 AM, François T. francoistarl...@gmail.com wrote:
Yes I do agree, but I don't see why the transformation would happen at the
EXR render. do you have a case ?
Any time you need to shift primaries.
Examples might include:
*) AdobeRGB images from a DSLR converted to sRGB for
On Jul 9, 2013 1:15 PM, Sergey Sharybin sergey@gmail.com wrote:
The root of the issue goes to the fact, that renderer always
outputs stuff in rec709 space (or in your language it'll be linear space
with rec709 primaries).
?
The renderer only renders with the values assigned, no?
Given
On Fri, Mar 11, 2011 at 8:19 AM, Ejner Fergo ejner...@gmail.com wrote:
In any case I hope you will consider including this updated camera.
Huge +1 here.
___
Bf-committers mailing list
Bf-committers@blender.org
@Mats Holmberg / @Francois T et al:
Is there a way we can establish a set of tests to definitively test this patch?
Obviously matching a scene to real world units against a test
photograph is a possible option here, but I'm wondering if there is
something else we can do?
Sincerely,
TJS
Whilst mucking about retiming, I noticed that I was unable to get any
sort of output shift on frame input to output ratio using the Time
Remapping Old and New values.
Has anyone tested it recently and gotten it to work? If so, what dark
alchemy did you invoke?
Sincerely,
TJS
On Sun, Mar 13, 2011 at 5:46 PM, Troy Sobotka troy.sobo...@gmail.com wrote:
Whilst mucking about retiming, I noticed that I was unable to get any
sort of output shift on frame input to output ratio using the Time
Remapping Old and New values.
Has anyone tested it recently and gotten
On Mar 23, 2011 11:39 AM, Tobias Oelgarte tobias.oelga...@googlemail.com
wrote:
The
feature works partially, but some strange things are happening:
Are you certain it still works in SVN? It seems potentially broken.
I would like to have this feature back or reimplemented, since it is the
only
On Sat, Apr 2, 2011 at 8:58 AM, pete larabell xgl.asyl...@gmail.com wrote:
Hi all... Just a quick update on the progress of this node. After a
few optimizations it is performing significantly better. The average
speed increase is upwards of 50x. I will have another build on
graphicall.org
While we are on this subject, shouldn't both CDL implementations for
color and saturation be implemented and tested against the spec?
http://en.wikipedia.org/wiki/ASC_CDL
___
Bf-committers mailing list
Bf-committers@blender.org
Just read Tom M's posting on LibMV and was wondering where the
discussions have taken place for it regarding future directions.
Nuke apparently (according to the User Guide[1]) harnesses VXL for
some of its algorithms. OpenCV, for example, has a simple relevant
point optical flow tracking example
On Sat, Apr 23, 2011 at 10:09 AM, Sergey I. Sharybin g.ula...@gmail.com wrote:
We're still using quite old version of ffmpeg for linux release builds
at least (this libraries were compiled from ffmpeg sources which were
used in blender source tree just before their remooving from the svn).
Long time coming, but with recent patch upgrades from Ejner Fergo I'm
wondering what the percentage chance we can see this appear in trunk?
http://projects.blender.org/tracker/?func=detailatid=127aid=24427group_id=9
___
Bf-committers mailing list
Just curious Julien, does your new code work with the ASC reference image
tests Andrew posted above?
With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
On May 18, 2011 10:56 AM, Andrew Hunter and...@aehunter.net wrote:
Perhaps you could assist us there?
Egads it would be most excellent to get someone with knowledge of coding
_and_ color management to help deal with the C / C++ compiling and linkage.
I have tried to short circuit the nodes
I believe if we can somehow hack Blender to deliver proper color spaces such
as REC601, REC709, etc., it is nothing short of tremendous value. Hack or
otherwise.
It also might help to diagnose imaging errors in Blender's pipeline.
Any suggestion on how best to deal with the C++ code in OIIO and
I finished reviewing the thread you pointed at Julien. Great find.
It appears that the consensus was that there is an implied transfer to a
film LUT within the file.
The traditional -profile conversion appears to work in that instance[1].
Is that what is muddling the issue here?
With respect,
due to the low feedback I'm getting fromunlimitedClay for Blender .. are
people still interested on it? I'm still here :(
This saddens me.
I believe much of what Tom posted above is relevant.
Right now, UC is unable to get into the hands and minds of the artists that
are most capable to run
On May 27, 2011 6:26 AM, Brecht Van Lommel brechtvanlom...@pandora.be
wrote:
Already discussed this on IRC, so just sending here for completeness.
I was sent this image which I think was made by David. The problems
shown there I can also redo in Gimp and Mypaint. It depends on the
brush
On Mon, Jun 27, 2011 at 11:12 AM, pete larabell xgl.asyl...@gmail.com wrote:
+1 on this.
I'll second this.
I find that both Nuke's panel approach and Blender's
within-the-node-itself approach have some advantages in certain
contexts.
Having, if I understand you correctly, a fluid layout for
On Tue, Jun 28, 2011 at 1:08 AM, j.bak...@atmind.nl j.bak...@atmind.nl wrote:
The brushes I already have an idea (required for the compositor branch),
the luminosity/saturation is something I didn't had an idea about, but this
can't be that difficult.
[..]
I currently don't see that many
Everything works great now, no jagged edges anymore.
Just to be clear, the entire decoding of motion picture footage for many
codecs is handled by ffmpeg.
So yes, this _was_ an ffmpeg issue. It lingered in Blender for anyone not
using updated ffmpegs I believe.
As blender didn't like the
On Wed, Jun 29, 2011 at 10:06 PM, j.bak...@atmind.nl j.bak...@atmind.nl wrote:
Patch is in the patchtracker. I currently only added the colorbalance as an
example. Will do other nodes as I go along the UI of the compositor.
While we are on the subject of the Color Balance node, should the ASC
Hello all. I've put four patches in the tracker. They are as follows:
SCALE NODE FILTER:
http://projects.blender.org/tracker/?func=detailaid=27974group_id=9atid=127
The default scale node doesn't allow the artist to choose between
available filter types. Considering a linear scale filter is
On Thu, Jul 14, 2011 at 6:16 PM, Blankfirstname Blanklastname
send.allemailst...@yahoo.com wrote:
Blender is suppose to be open and free and with this
one snafu, Blender is no longer open and free.
Actually, I just checked. The source code is indeed open and free
still, but that was of two
Can anyone cite where Blender's internal representation of middle grey
is? Has one been defined?
It would seem that for ingestion and output, the reference model would
be wise to locate one. For example, within Open Color IO, the
reference compositing space appears to select a value that aligns
So far, I've been experimenting with several files and uptake tools
using Blender in conjunction with Nuke. I have yet to be able to find
a pattern that delivers proper alpha channels.Perhaps someone here can
shed some light on the matter.
It has been noted before that there has been some
Just thought I'd point out that Mr. Selan is holding an Open Color IO
BOF at Siggraph. There is also a Beer of a Feather for all of SPI's
open source projects at Siggraph.
Might be interesting if the Blender peeps attend, especially
considering the integration of OCIO and OIIO into Blender.
On Sun, Jul 31, 2011 at 9:47 AM, Ton Roosendaal t...@blender.org wrote:
Welcome Sergey! :)
Congratulations Sergey. Well deserved sir.
With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
On Sun, Aug 21, 2011 at 11:13 AM, Shaul Kedem shaul.ke...@gmail.com wrote:
- Ton reports Development Fund is reaching 1000/month. Will contact
Jeroen Bakker to discuss OpenCL compositor project completion.
While we are on this subject, is there any chance that we might be
able to put OCIO
http://projects.blender.org/tracker/?func=detailatid=498aid=28085group_id=9
Thanks to anyone that can find time to check in on the patch.
With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
Droid was likely heavily optimized for smaller screens which may have
influenced the tracking at smaller sizes.
If anyone knows where to set the default point size in Blender, it might be
worth bumping it a point to see if the tracking lightens up a bit.
The baseline for the UI would also need
In the ever ongoing deluxe saga of trying to get Blender to correctly
ingest premultiplied alpha images such as TIFFs, the following patch
is offered for review. Special thanks go to Brecht for his extreme
patience and sagely advice.
ATTN: This patch also adds in the three lines of code to
Thanks for looking Brecht. Some clarifications as discussed via IRC
but put here for posterity and searching:
On Fri, Sep 30, 2011 at 7:37 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
* The BLI_CM_ should not be in blenlib, there should be separate flags
in DNA_image_types.h and
Can we start a new thread discussing the design constraints on the default
typeface perhaps?
With respect,
TJS
On Oct 23, 2011 4:39 PM, Matt Ebb m...@mke3.net wrote:
On Mon, Oct 24, 2011 at 10:21 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Hi all,
Here's a patch with a
Great to finally see some discussion on this topic.
On Dec 15, 2011 6:32 AM, Brecht Van Lommel brechtvanlom...@pandora.be
wrote:
You might notice I'm not really mentioning OIIO/OCIO. It's a nice
project to integrate those, but it doesn't solve current issues and is
fairly orthogonal to the
On Dec 15, 2011 1:24 PM, Jason van Gumster ja...@handturkeystudios.com
wrote:
I understand the necessity/convenience of internally choosing one alpha
format
over the other. However, I'm curious how this would impact saving to image
formats that only support one alpha format (e.g. premultiplied
On Dec 15, 2011 11:50 PM, Bartek Skorupa bartekskor...@bartekskorupa.com
wrote:
Re wiki page: When explaining math behind mixing Over image with
background (straight alpha) it should be: [(Over.RGB * Over.Alpha) +
(Background.RGB * (1 - Over.Alpha))].
Formula at the page is: [(Over.RGB *
James Ruan ruanbeih...@gmail.com wrote:
The use of premultiplied alpha format is to save some computing time.
This is certainly a byproduct, but not entirely correct for associated
alpha's existence. It is mandatory state for correct convolution
operations and luminescent over adds.
Jeremy
I thought I'd add the infamous thread over at Adobe here regarding
associated versus unassociated alpha in the context of a system that
needs to support various formats.
In this case, for those unfamiliar, this was the thread in which Adobe
responded to their (mis) handling of the EXR format.
Brecht wrote:
So perhaps there's still toggles needed to control if these operations
should happen on premul/key alpha (for image load/save, and for color
correction nodes).
+1. I still believe this is fundamentally mandatory.
Matt wrote:
That infamous Adobe thread has interesting background
On Dec 20, 2011 10:41 PM, James Ruan ruanbeih...@gmail.com wrote:
Certainly, every image entering the
composite system must indicates its format and outputs a straight
alpha( actually recommended) to the system.
Recommended? I would need some citations as just about every industry
compositor
On Wed, Dec 21, 2011 at 11:22 AM, gespert...@gmail.com
gespert...@gmail.com wrote:
uh, oh! Luminescent premul doesn't seem to be possible in Blender either.
The alpha-over node seems to be skipping pixels with alpha=0 from the
second operator.
http://ubuntuone.com/4vtqL5bN74wMfsBbl9QkMZ
Troy
There seems to be quite a bit of confusion with regards to the two
different buffer formats in Blender and how they are handled
internally.
From an artist perspective, this is deadly complicated as if you are,
for example, painting in 8 bpc sRGB space, your overs are not linear
whereas in 32 bpc,
Not sure the last mail got through as I attached a JPG. I've also
bumped it to fix some rather glaring formatting boo boos I created.
Screenshot:
http://img259.imageshack.us/img259/9556/infosample.jpg
Patch:
http://projects.blender.org/tracker/index.php?func=detailaid=29754group_id=9atid=127
I thought I'd point out that as of r43004 both associated and
unassociated alpha can now be properly handled for non-linear formats
such as TIFF.
A tremendous thanks to Brecht for the fix.
The TL; DR for Blender artists:
When importing a non-linear associated alpha image, artists should
always
Campbell can probably answer this as I suspect the lines in question
are probably from pre 2.5x lineage.
Since we migrated the FFMPEG to a full RNA structure with presets in
the scripts folder, I was wondering if we still required lines
1253-1344 of writeffmpeg.c?
It appeared that the lines in
Seeing as how we hit a stalemate with the potential of trying to get a
low level implementation of color management into Blender, I am hoping
that we can include Jeroen's massively useful OCIO node. It is already
written, worked wonderfully, and of tremendous value.
Perhaps we could consider this
While it is great to be discussing Blender's UI, I would hope that it
may be acceptable to put Mr. Roosendaal's recent comment on a request
at the top of the page:
Instead of explaining why you need it, or calling it better or
more useful, just write down a neutral and very precise
specification
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
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
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
Thought I'd follow up the confusing discussions with a Wiki page.
http://wiki.blender.org/index.php/User:Sobotka/Associated_and_Unassociated_Alpha
With respect,
TJS
PS: Corrections and questions are not only welcome, but encouraged. If
you wish to keep it off list, feel completely free to email
Greetings all.
I've finished writing a patch that adds cubic b-spline with prefilter
scaling to Sergey's most awesome Transform node.
I'd hope that everyone can appreciate the quality that it brings to
the table for the artists around Blender. It's a significantly
impressive algorithm that I'd
On Mar 5, 2012 1:32 PM, Campbell Barton ideasma...@gmail.com wrote:
The reason support for saving non-linear Imbufs was added is because
float sequencer buffers were not linear (internally AFAIK they are
still not - this is needed for sequencer float blending which differs
with linear
1 - 100 of 150 matches
Mail list logo
