The file formats now fill in ImColorSpaceInfo with the metadata colorspace
and a boolean saying if the pixels have HDR colors. And then the actual
colorspace is decided in imb_handle_colorspace_and_alpha.
This centralizes the logic in one place to make it possible to add
OpenColorIO file rules.
Pull Request: https://projects.blender.org/blender/blender/pulls/136516
Set the flags on the image buffer when loading an EXR file, so they can be
used when saving.
This also removes IB_halffloat and replaces it by the file options flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/135656
The File Output node crashes when saving a 16-bit vector image in an
RGBA image. That's because the OIIO writer assumes 4-channel buffer
while the buffer provided by the node is only 3-channel. To fix this,
the OIIO writer is extended to support all possible combination of
source and target channels.
Pull Request: https://projects.blender.org/blender/blender/pulls/134789
In some/many cases, an `ImBuf` is allocated, and all the pixels are
immediately filled by some code. Doing the memory clear within allocation
is just memory traffic for no good reason.
Add a flag to skip initialization of ImBuf pixels (IB_uninitialized_pixels)
and use that in some parts of VSE effects/rendering/cache/scopes, as well
as image loading code.
Rendering out VSE movie, on Windows/VS2022/Ryzen5950X:
- Sprite Fright: 443sec -> 414sec (takes 93% of previous time)
- Gold previs: 367sec -> 325sec (takes 88% of prev time)
Pull Request: https://projects.blender.org/blender/blender/pulls/118321
Now that OIIO has proper `valid_file` APIs for the formats we care
about, and which take MemReaders, we can remove the code added to TIFF,
PSD, and PNG as part of 5cc8fea7e9.
Additionally, this change eliminates the recent console spew on startup
where the TIFF loader is asked to load non-TIFF files (it is based on
the ordering of the filetype array)[1]. We now make a `valid_file` check
during open to address this.
[1] `: Not a TIFF or MDI file, bad magic number 12150 (0x2f76).`
Pull Request: https://projects.blender.org/blender/blender/pulls/116826
It's possible to encounter a true 1-channel image if it's coming
directly from, say, a float-value AOV or similar.
This was not accounted for and would cause issues when saving the image
out to a 3 or 4 channel format (wrong values) or when saving out to
another 1 channel format (unnecessary usage of luminance weight values).
Pull Request: https://projects.blender.org/blender/blender/pulls/111577
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
The goal is to make it more explicit and centralized operation to
assign and steal buffer data, with proper ownership tracking.
The buffers and ownership flags are wrapped into their dedicated
structures now.
There should be no functional changes currently, it is a preparation
for allowing implicit sharing of the ImBuf buffers. Additionally, in
the future it is possible to more buffer-specific information (such
as color space) next to the buffer data itself. It is also possible
to clean up the allocation flags (IB_rect, ...) to give them more
clear naming and not have stored in the ImBuf->flags as they are only
needed for allocation.
The most dangerous part of this change is the change of byte buffer
data from `int*` to `uint8_t*`. In a lot of cases the byte buffer was
cast to `uchar*`, so those casts are now gone. But some code is
operating on `int*` so now there are casts in there. In practice this
should be fine, since we only support 64bit platforms, so allocations
are aligned. The real things to watch out for here is the fact that
allocation and offsetting from the byte buffer now need an explicit 4
channel multiplier.
Once everything is C++ it will be possible to simplify public
functions even further.
Pull Request: https://projects.blender.org/blender/blender/pulls/107609
Fix several issues found while investigating missing browser thumbnails.
TIFF, PSD, and PNG now use their old file check code. This is due to
OIIO not having an early-out check within `.open`. Calling `.open`
required a large portion of the file to be available (more than 8192
bytes). The code here can be removed in the future if/when a new API is
available which alleviates this problem.
PSD files often carry along a large blob of ICCProfile metadata.
Attempting to roundtrip this metadata when we cache the thumbnail to
.png was leading to problems. We suppress this metadata now as ICC
profiles are not supported in general and are quite large.
Lastly, even after the mentioned new API is available, OIIO will want to
validate the full header of some file formats. DPX is the largest at a
full 2048 bytes so we must have this as our minimum now too. OS's should
be servicing this read call just as efficiently as when using 64. I
could spot no performance difference here at least.
This was missed during development because Blender will cache thumbnails
into a special .thumbnails directory and the images I was using to test
had already been cached there.
Pull Request: https://projects.blender.org/blender/blender/pulls/107515
The call to `channel_sum` requires that the `weights` array is at least
as large as the number of channels in the originating buffer.
Switch to use the span overload as well since the method that takes a
raw weights array is deprecated.
Thanks to @aras_p for debugging the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/106847
This checkin will use OIIO to replace the image save/load code for BMP,
DDS, DPX, HDR, PNG, TGA, and TIFF.
This simplifies our build environment, reduces binary duplication,
removes large amounts of hard to maintain code, and fixes some bugs
along the way.
It should also help reduce rare differences between Blender and Cycles
which already uses OIIO for most situations. Or potentially makes them
easier to solve once discovered.
This is a continuation of the work for #101413
Pull Request: https://projects.blender.org/blender/blender/pulls/105785
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
This adds a new set of APIs supporting the loading and saving of image
formats through OIIO. It makes use of the recent IOProxy work in OIIO
to align with the existing Blender image loading/saving machinery.
The support code here has been prototyped to work with ~7 of our image
formats so far. It includes centralized handling of `IB_test`,
`IB_mem`, and `IB_metadata` flags, which the existing code did not
handle consistently or at all depending on the format.
The PSD format (`format_psd.cc`) is included since the prior location
of the code has been restructured away. It serves as an example of how
the loading code typically flows for all the other formats.
Pull Request: https://projects.blender.org/blender/blender/pulls/105519
