| Age | Commit message (Collapse) | Author |
|---|
|
Before alpha channel was simply ignored causing bad looking
straight colors which is pretty much useless.
Now saving RGB would alpha-over image on top of black color,
which makes final image look really nice. It's also very
such the same what other graphics software does this.
In the future we could easily support configurable backdrop
color, which would be really the same as other SW does it.
Also, it'll probably worth adding the same mode to RGB
display of image editor.
|
|
to include a few more that gcc is using too.
|
|
|
|
16bit PNG and Jpeg2K exporters were not aware of the simple
fact that float buffer could have only 3 or 1 channels.
|
|
conflicted with one from IMB_colormanagement.h
|
|
style edits and typo corrections.
|
|
alpha was used for them which doesn't work for cleaned footage stored
in EXR file format.
Perhaps we need to support configurable alpha mode for clips, but
that's for later (maybe even after release),
|
|
make sure it works if this function gets called from other places.
|
|
Adding non-RGBA float buffers as texture crashes MipMap code.
Images with less than 4 channels not supported (yet). Not sure
if we ever should even... normals, Z, vectors, UV, Index, all
don't like downsampling.
|
|
|
|
Used by image painting mode, so every brush step would mark area
if affected on, but actual color space conversion would happen
later when actually displaying image.
Implemented as a rcti stored in ImBuf which is getting merged with
partial rect passed to IMB_partial_display_buffer_update_delayed.
This makes painting as fast as it currently possible and finally
solves #33935: Texture painting slow down with mouse, but not with tablet
|
|
|
|
Multilayer files saved from Maya (and I bet others) store the 'primary' layer without
layer or pass name, just as R G B A. Allows viewers to show stuff too, I guess.
Blender now reads this as well, just allowing an empty string for the layer and pass.
|
|
Issue is solved for painting on byte buffer with default sRGB display enabled.
In this case it is possible to skip any color space transform and just apply
dither if needed.
Still not sure if there's a regression in painting on flaots or not, will
continue investigation.
|
|
Own mistake in 16bit PNG support, wrong bitmask for custom flags
ftype really needs cleanup..
|
|
was enabled.
|
|
also cast strlen to an int to avoid overflow.
|
|
|
|
|
|
|
|
|
|
16bit PNG images were not doing any conversions when saving linear float buffers, but would always load them as SRGB.
apply the same method used for 16bit images from floats as used in jpeg2000.
|
|
the existence of a float buffer can depend on the image being used in the compositor for example, so better give the user what they expect - 16bit png if its selected from the UI.
|
|
Patch makes it possible to compile blender with recent ffmpeg
and libav libraries, mainly by getting rid of deprecated API.
Original patch by Campbell Barton with own modifications to
support compilation with older ffmpeg versions.
This patch could break compatibility of FFV1 videos playing
back in older players, mainly because of alpha support changes.
Preserving compatibility with such players became a headache
and think it's high time to get rid of workarounds here.
|
|
|
|
Also fixed typo in function name.
|
|
Exposure shouldn't affect on alpha channel, only RGB shall be
affected by exposure.
Was a regression since recent alpha premul pipeline changes.
|
|
Also marked some TODOs as actually solved.
|
|
|
|
without hurting quick texture painting
- ED_view3d_draw_offscreen will now output buffer with
transparent alpha, if sky needed it should be alpha-undered
later.
- ED_view3d_draw_offscreen_imbuf now accepts alpha mode as an
argument which could be either R_ADDSKY or R_PREMULALPHA
- OpenGL render and sequencer's opengl preview will now reflect
scene's Alpha Mode
- Quick Edit will use OpenGL with transparent alpha mode
|
|
Additional changes:
- Made mipmapping operate with unsigned short instead of char
which allowed to eliminate extra division by 255, so prevision
should be a bit better now.
- Actually, this is not real unsigned short range, but it's a
range of 255*255 which is more convenient for mipmapping, so
made conversion functions private for scaling.c
Not sure it worth making this functions operate in 65535
range, for now current behavior seems to be just fine.
|
|
Regression was caused by alpha premul cleanup commit and the reason
of slowdown was uchar <-> float conversion which is slow.
Replaced with uchar <-> int conversion which seeps to be accurate
enough and mostly eliminates slowdown.
Slowdown was easy to notice when movie clip is used for 3d vierport
background and undistortion is enabled. In this case every frame
will re-calculate mipmaps.
It's still a nit slower than mipmap generation before cleanup
commit, but couldn't think about extra boost here atm.
|
|
Misunderstand flag of file filter, should work fine now.
|
|
|
|
This assumptions are now made:
- Internally float buffers are always linear alpha-premul colors
- Readers should worry about delivering float buffers with that
assumptions.
- There's an input image setting to say whether it's stored with
straight/premul alpha on the disk.
- Byte buffers are now assumed have straight alpha, readers should
deliver straight alpha.
Some implementation details:
- Removed scene's color unpremultiply setting, which was very
much confusing and was wrong for default settings.
Now all renderers assumes to deliver premultiplied alpha.
- IMB_buffer_byte_from_float will now linearize alpha when
converting from buffer.
- Sequencer's effects were changed to assume bytes have got
straight alpha. Most of effects will work with bytes still,
however for glow it was more tricky to avoid data loss, so
there's a commented out glow implementation which converts
byte buffer to floats first, operates on floats and returns
bytes back. It's slower and not sure if it should actually
be used -- who're using glow on alpha anyway?
- Sequencer modifiers should also be working nice with straight
bytes now.
- GLSL preview will predivide float textures to make nice shading,
shading with byte textures worked nice (GLSL was assuming straight
alpha).
- Blender Internal will set alpha=1 to the whole sky. The same
happens in Cycles and there's no way to avoid this -- sky is
neither straight nor premul and doesn't fit color pipeline well.
- Straight alpha mode for render result was also eliminated.
- Conversion to correct alpha need to be done before linearizing
float buffer.
- TIFF will now load and save files with proper alpha mode setting
in file meta data header.
- Remove Use Alpha from texture mapping and replaced with image
datablock setting.
Behaves much more predictable and clear from code point of view
and solves possible regressions when non-premultiplied images were
used as textures with ignoring alpha channel.
|
|
This commit adds a support of saving 16bit PNG files.
Alpha for such files would be premultiplied, would be corrected
with an upcoming alpha premul cleanup (it's not the only format
which will output 16bit image with premul alpha).
|
|
|
|
|
|
be fixed in the icons code!
|
|
(Used for icon mipmap)
|
|
This codec is absolutely needed to generate DCP using OpenDCP,
before that external application to convert JP2 to J2K was used
which slowed down export a lot.
New codec is exposed to image format settings panel and called
Codec. Default one is JP2 which creates files with .jp2 extension,
new one is called J2K which creates with .j2c extension.
Other changes:
- Fixed avi jpeg warning which was treating as error here.
- Made it so extension is detecting from ImageFormatData instead
of image file type, which makes it possible to have different
extension for the same file type depending on it's settings.
IRIS format should still be changed (depending on number of
channels it'll be .bw, .rgb or .rgba extension)
- Default image format settings would be set from image buffer
when re-saving it. Makes it possible to easily open .j2c file
and save it using J2K codec (without this change it'll save as
.jp2 using JP2 codec)
|
|
|
|
|
|
|
|
Also changed shebang to '#!/usr/bin/env python', this is more portable across unixes...
|
|
|
|
This was a regression in svn rev52718 caused by the fact that we can not
free packet fun until we've finished all manipulation with decoded frame
since frame and packet could share same pointers.
For now restored old behavior of next_packet which seems to be well
tested and better not do bigger refactoring here so close to release.
Memory leak fixed by that revision was fixed by calling av_free_packet
just before avcodec_decode_video2 in cases we're at the end of file.
Tested with valgrind and could not see any memory leaks in ffmpeg
area.
|
|
|
|
This fixes a memory leak caused by the last packet on stream EOF not freed.
(Memory leak occurs on ffmpeg heap managed by av_malloc / av_free, so it is
invisible to Blender)
Also: clean up the code a little bit (anim->next_packet was never really used,
so could be moved into a local variable)
|
|
|
