| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It was a threading issue in color management project which potentially
could happen in trunk as well.
|
|
- new compositor could use uninitialized var
- profile conversion could use uninitialized var
- set better warnings for clang+cmake.
- remove picky warnings from sphinx doc gen shell script.
|
|
|
|
|
|
else if's
|
|
Bugfix: [#28159] sequencer strip crop values on proxy not scene render size
Also: IMB saturation change moved into imbuf-module.
|
|
spelling 'impliment' -> 'implement'
|
|
viewport/ the Nyan cat bug.
Issue is caused by scaling for power of 2 dimensions and mipmapping that happens through GLU. It looks like the library cannot handle float colour values above 1.0 correctly. Since we are close to release I will just clamp the srgb result for now even though it will result in a small performance loss for 16 bit textures only.
I tried a few things before that, glGenerateMipmaps + no scaling (supported for 2.0 GL hardware and up), or using our own scaling instead of glu among them which worked very nicely and gave a speedup too. However, since we are close to release and there may be issues with GPU mipmap generation, see:
http://www.gamedev.net/topic/495747-another-glgeneratemipmap-question/
(old discussion but better be sure than sorry)
I went for the most compatible solution. Maybe after release this can be tested if other devs agree.
|
|
conversion in case of invalid input.
|
|
also add rgba_float_to_uchar, rgba_uchar_to_float
|
|
|
|
* Accelerated sRGB <=> linear conversion using lookup table, this can speed up
loading of images in the compositor and simple renders quite a bit.
* Dithering now uses the Floyd-Steinberg algorithm. Previously it would simply
randomize each pixel slightly, adding noise, now that should be reduced.
Patch #29309 by David M.
|
|
|
|
settings.
For premultiplied alpha images, this makes any color space conversion for the image
or render output work on color without alpha multiplied in.
This is typically useful to avoid fringing when the image was or will be composited
over a light background. If the image will be composited over a black background on
the other hand, leaving this option off will give correct results.
In an ideal world, there should never be any color space conversion on images with
alpha, since it's undefined what to do then, but in practice it's useful to have
this option.
Patch by Troy Sobotka, with changes by me.
|
|
byte => float, float => float, byte => byte conversions with profile, dither
and predivide. Previously code for this was spread out too much.
There should be no functional changes, this is so the predivide/table/dither
patches can work correctly.
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
convert to grayscale when saving renders rather then only writing the red channel.
|
|
This fix also allows for partial update of the image, speeding up painting.
The different code path implemented will be used to upload high resolution images to OpenGL when onion branch is merged.
Due to conversion of float textures to/from sRGB, corrections made to brush color sampling to take account of the image profile. This is not 100% correct yet as texture images used for projection painting strokes are not converted to/from sRGB yet(This has been decided due to loss of precision for 8-bit formats). It will have to do for now, though.
last-minute update, exr image loading is broken, will fix asap
|
|
doubles, adjust to use floats.
|
|
|
|
|
|
|
|
Three code fixes for 1 report. User experienced crashes while
painting on float buffer + having preview renders on.
- Texture Nodes: Image was re-allocated without using
proper thread lock
- Paint code: old convention to free the byte rect from
a float image as signal to re-create now is a proper
flag. This keeps image memory unchanged. Nice for render.
- Imbuf: call to make a byte rect from float was freeing
mipmaps unnecessary.
|
|
also minor functional changes
- OBJECT_OT_make_links_data() type property is now assigned to the operator property (so popup menu can find it)
- removing BG image now returns cancelled if no image is removed.
|
|
|
|
- move GS() define into DNA_ID.h
- add BLI_utildefines as an automatic include with makesrna generated files.
|
|
MAKE_ID, FILE_MAXDIR, moved the generic defines to BLI_utildefines.h.
no functional changes.
|
|
Sequencer crash when combining a scene strip with image strip and cross.
Code lacked proper check for byte buffer in scene...
|
|
- a linear float buffer was being created and saved into a non-linear DPX/Cineon file.
- removed the UI since the settings are not used at the moment.
added a utility function IMB_float_profile_ensure(), which returns a float buffer in the requested profile, using the existing if needed or returning an allocated buffer if the profile is different to that of the ImBuf. - Useful this case where the save function has its own linear setting.
|
|
initializers is a c99 feature.
|
|
- removed deprecated bitmap arg from IMB_allocImBuf (plugins will need updating).
- mostly tagged UNUSED() since some of these functions look like they may need to have the arguments used later.
|
|
inconsistantly, some places used colorspace conversion, some not.
Added IMB_float_from_rect_simple() for the sequencer to use.
|
|
tile cache code in imbuf, but it is not hooked up to the render engine.
Imbuf module: some small refactoring and removing a lot of unused or old code
(about 6.5k lines).
* Added a ImFileType struct with callbacks to make adding an file format type,
or making changes to the API easier.
* Move imbuf init/exit code into IMB_init()/IMB_exit() functions.
* Increased mipmap levels from 10 to 20, you run into this limit already with
a 2k image.
* Removed hamx, amiga, anim5 format support.
* Removed colormap saving, only simple colormap code now for reading tga.
* Removed gen_dynlibtiff.py, editing this is almost as much work as just
editing the code directly.
* Functions removed that were only used for sequencer plugin API:
IMB_anim_nextpic, IMB_clever_double, IMB_antialias, IMB_gamwarp,
IMB_scalefieldImBuf, IMB_scalefastfieldImBuf, IMB_onethird, IMB_halflace,
IMB_dit0, IMB_dit2, IMB_cspace
* Write metadata info into OpenEXR images. Can be viewed with the command
line utility 'exrheader'
For the image tile cache code, see this page:
http://wiki.blender.org/index.php/Dev:2.5/Source/Imaging/ImageTileCache
|
|
|
|
|
|
|
|
- fix for compiler warnigns
- bpath reporting was incorrect
|
|
Now it's a bit more robust, tagging images with profiles when they're loaded,
which then get interpreted later on by conversion functions. Just Linear RGB
and sRGB profiles at the moment, same as before.
This commit fixes Martin's problem with EXRs and Multilayer images loading/
saving too dark, and it also makes the sequence editor work correctly with it too.
Also fixes:
[#19647] gamma correction with color management is reset when resetting Curve
[#19454] 2.5: Dither does not work when Color management is enabled
|
|
management
was missing include
|
|
float to byte was not working correct.
|
|
- 1st stage: Linear Workflow
This implements automatic linear workflow in Blender's renderer. With the
new Colour Management option on in the Render buttons, all inputs to the
renderer and compositor are converted to linear colour space before
rendering, and gamma corrected afterwards. In essence, this makes all
manual gamma correction with nodes, etc unnecessary, since it's done
automatically through the pipeline.
It's all explained much better in the notes/doc here, so please have a look:
http://wiki.blender.org/index.php/Dev:Source/Blender/Architecture/Colour_Management
And an example of the sort of difference it makes:
http://mke3.net/blender/devel/rendering/b25_colormanagement_test01.jpg
This also enables Colour Management in the default B.blend, and changes the
default lamp falloff to inverse square, which is more correct, and much
easier to use now it's all gamma corrected properly.
Next step is to look into profiles/soft proofing for the compositor.
Thanks to brecht for reviewing and fixing some oversights!
|
|
This unifies all usage of FTOCHAR, putting it in utildefines.h
Submitter did several interesting tests for speed, check it here:
http://projects.blender.org/tracker/?func=detail&atid=127&aid=8461&group_id=9
|
|
blocks that were previously missed; and b) greatly increase my
ohloh stats!
|
|
The conversion from float to char (byte) was not correct. It should include
the possibility for colors like 0.999999 to become 255 still. The correct
multiplication factor I don't know though... and this should become a system
wide definition!
|
|
Please read:
http://www.blender3d.org/cms/Imaging.834.0.html
Or in short:
- adding MultiLayer Image support
- recoded entire Image API
- better integration of movie/sequence Images
Was a whole load of work... went down for a week to do this. So, will need
a lot of testing! Will be in irc all evening.
|
|
- blur works again (this was a serious bug in gamwarp...)
- seperates all sequence effects into a seperate file with a clean interface
- thereby fixing some obscure segfaults
- seperates the scope views into a seperate file
- adds float support to all effects and scope views
- removes a bad level call to open_plugin_seq
- FFMPEG seeking improved a lot.
- FFMPEG compiles with debian sarge version cleanly
- Makes hdaudio seek and resample code really work
|
|
This now is a post-process option only (used to be in render).
It is only handled within the Imbuf/ module, on conversions from float
to byte rect, which atm mostly happens on saving images.
- Small fix: when using Scene RenderLayer nodes, the speed vectors for
these nodes were not created when that scene had "Do Composite" off.
|
|
- cleanup of color curves code; goes at least twice faster now!
(includes black/white point stuff)
- When using 'Curves' in image window on a byte rect, it creates a (temp)
float rect to operate on. So curves work for regular pictures too now.
|
|
Until now, the zbuffer was written straight from the internal zbuffer,
which has values that are inverse-proportional (like 1.0/z) which makes
it very hard to use it for postprocess, like zblur or other composit effects
that require Z.
Based on info from ILM, the values stored for Z in exr files is the
actual distance from a camera. I think that's about time to migrate to that
convention!
By default now, after render, the z values are converted to floats. This
saves in exr files now, but not in the Iris Z files. That latter was a
blender-only anyway, so might be not a real hassle to drop. :)
You can see the difference in the image window, but notice the range now
is linear mapped from camera clipstart to clipend.
Note; I just discover that ortho Z values need a different correction...
|
