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/
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
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
