This replaces per-image editor curve mapping which didn't behave properly
(it was possible to open the same image in two image editors and setup
different curves in this editors, but only last changed curve was applied
on image)
After discussion with Brecht decided to have something which works reliable
and predictable and ended up with adding RGB curves as a part of display
transform, which is applied before OCIO processor (to match old behavior).
Setting white/black values from image editor (Ctrl/Shift + LMB) would
affect on scene settings.
This could break compatibility, but there's no reliable way to convert
old semi-working settings into new one.
Mainly behaves in the same way as legacy color transformation, but it'll
give different result on over and under exposured areas.
Not sure if it's indeed issue -- seems this behaves crappy in both of
current stable release and OCIO branch.
This gives some percentage of speedup, which compensates slowdown
caused by converting image buffer into display space.
Used OpenMP for this. Still feel skeptic about this, discussed with
Brecht and we decided this approach actually could be used since
seems all the platforms has got OpenMP issues solved.
Waveform and vector scopes are still single-threaded since they're
a bit tricker to be done multi-threaded and probably not so commonly
used.
This avoids calculation of scopes on every redraw, so such tools as panning
and zoom wouldn't imply re-calculating scopes.
Implemented as a structure inside of SpaceSeq, juts like it's done for clip
and image spaces.
Also fixed zebra display to work in display space.
Added utility function to apply display transformation on image buffer's
float array which is currently only used by sequencer's scopes.
This function is multithreaded, but scopes should be improved further
since currently they're being recalculated from scratch on every draw.
- Color managed RGB values wouldn't be displayed anymore for
byte images (which are currently unsupported to be managed).
- Color rectangle would now be color managed
- Sequencer was passing non-linear float to information line,
now it'll pass linear float.
This tonemap was added as a temporary option only and if it'll be
needed again, it'll be better to implement is as either a spline
in OCIO or as a film response curve (as some of such curves were
added as a presets for RGB curves in Mango production SVN).
Also revert changes made to IMB_buffer_byte_from_float since it's
not actually needed anymore and makes it's clearer changes against
trunk.
Avoid using tricks with ibuf->profile to check whether image buffer is
in sequencer or linear space. Assume the whole sequencer works in non
linear float space and do transformation to linear where it;s needed
only.
This removes confusion from the code, fixes wrong behavior of some
effects.
Makes it possible to investigate color managed ranges.
Not ideal but it's the quickest thing which could be done to remove
current grading stoppers for Mango.
- Add check for header field in BMP decoder. This is needed to distinguish
whether file is indeed BMP image or not.
Without this check Blender could easily crash when it'll try to load
non-BMP image.
Tested with files from own HDD, but all of them has got BM header field,
more testing would be welcome.
- Made Jpeg2000 aware of J2K codec. Originally was needed to verify .j2c
files here in the studio, but having support of this codec would be
nice in general.
Currently supports only reading in this codec, writing would still
using jp2 codec.
- Even preserves thickness but can give unsightly loops
- Smooth gives nicer shape but can give unsightly feather/spline mismatch for 'S' shapes created by beziers.
This is an example where smooth works much nicer.
http://www.graphicall.org/ftp/ideasman42/mask_compare.png
