lp:~cgi-daily-devs/cgi-daily/+git/openimageio

Owned by cgi-daily
Get this repository:
git clone https://git.launchpad.net/~cgi-daily-devs/cgi-daily/+git/openimageio

Import details

Import Status: Reviewed

This repository is an import of the Git repository at https://github.com/OpenImageIO/oiio.git.

The next import is scheduled to run .

Last successful import was .

Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 2 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-2 and finished taking 50 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 40 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 1 minute — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 2 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 1 minute — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 1 minute — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 40 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 1 minute — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 50 seconds — see the log

Branches

Name Last Modified Last Commit
dev-2.6.1 2024-06-27 20:08:27 UTC
fix(psd): various PSD files fail to load correctly (#4302)

Author: Jesse Yurkovich
Author Date: 2024-06-22 22:16:40 UTC

fix(psd): various PSD files fail to load correctly (#4302)

The primary issue seemed to be that the ChannelInfo width and height
were not filled in for some of the layers, notably the merged image data
layer in most(all?) cases.

A second issue was that there was incorrect nesting of the switch
statement in `read_channel_row`. The last 3 case statements were all
nested under the `if (!bigendian()) {` conditional from the 1st case.

Fixes #4298

## Tests

Use `iconvert` on all PSD files contained in the attached .zip.
Converting to both .exr and .png is a good test to ensure the data is
flowing out to those formats correctly.
[psd.zip](https://github.com/user-attachments/files/15905814/psd.zip)

---------

Signed-off-by: Jesse Yurkovich <jesse.y@gmail.com>

master 2024-06-27 15:41:33 UTC
fix(png): Correctly read PNGs with partial alpha (#4315)

Author: Larry Gritz
Author Date: 2024-06-27 15:41:33 UTC

fix(png): Correctly read PNGs with partial alpha (#4315)

TL;DR: when turning unassociated alpha into associated for
gamma-corrected PNG images, we got the exponent wrong for the
linearization step, and when doing the same for sRGB images, we didn't
linearize at all.

WARNING: will change appearance of PNG files with partial alpha.

Details:

Ugh, two separate problems related to how we associate alpha (i.e.
premultiply the colors) for PNG pixels with partial alpha. The correct
thing to do is linearize the unassociated pixel value first, then
associate, then go back to the nonlinear space.

First problem: PNGs have three possible transfer functions: gamma
correction (with a particular gamma), no gamma correction / linear, and
explicitly sRGB. Guess what? We were neglecting the case of pngs tagged
as sRGB and not doing the linearize/delinearize round trip for those
images.

But if that's not enough, also for the gamma case, we were, ugh,
swapping the gamma and 1/gamma, resulting in those partial alpha pixels
ending up a whole lot darker than they should have been.

None of this affected most ordinary PNGs with no alpha channel, or where
alpha was 1.0. It only affected "edge" or "partially transparent" pixels
with 0 < alpha < 1. But it was definitely wrong before, for which I
apologize and hope you'll understand why those pixels are going to
change now (hopefully, always always for the better).

While I was at it, I also made the color space handling a little more
robust -- instead of just a straight string compare for color space
names, use the ColorConfig to check `equivalent`, which should make us a
lot more robust against aliases and whatnot.

Fixes #4314
Closes #4054

---------

Signed-off-by: Larry Gritz <lg@larrygritz.com>

dev-2.5 2024-06-27 05:42:43 UTC
docs: Fixes to formatting and sphinx warnings (#4301)

Author: Larry Gritz
Author Date: 2024-06-20 18:19:10 UTC

docs: Fixes to formatting and sphinx warnings (#4301)

Also, tell doxygen to use multiple threads.

Signed-off-by: Larry Gritz <lg@larrygritz.com>

rtd 2024-06-19 01:29:28 UTC
perpixel_op docs

Author: Larry Gritz
Author Date: 2024-06-18 23:53:14 UTC

perpixel_op docs

Signed-off-by: Larry Gritz <lg@larrygritz.com>

release 2024-06-01 19:59:05 UTC
Stage for v2.5.12.0

Author: Larry Gritz
Author Date: 2024-06-01 19:49:42 UTC

Stage for v2.5.12.0

Signed-off-by: Larry Gritz <lg@larrygritz.com>

lg-sonaronly 2024-03-02 04:11:46 UTC
int(simd.h): Make the simd types trivially_copyable

Author: Larry Gritz
Author Date: 2024-01-14 01:49:08 UTC

int(simd.h): Make the simd types trivially_copyable

Basically, this is a way of saying memcpy of any of these simd types
is fine. It doesn't matter a lot for OIIO itself, but it helps quiet
some static analysis warnings for OSL.

Signed-off-by: Larry Gritz <lg@larrygritz.com>

dev-2.4 2023-11-02 01:16:02 UTC
admin: Fix typo in slack-release-notifier version (#4046)

Author: Larry Gritz
Author Date: 2023-11-02 01:10:26 UTC

admin: Fix typo in slack-release-notifier version (#4046)

Signed-off-by: Larry Gritz <lg@larrygritz.com>

dev-2.5.0 2023-03-08 21:55:14 UTC
Bump version to 2.5.0.3

Author: Larry Gritz
Author Date: 2023-03-08 19:10:40 UTC

Bump version to 2.5.0.3

sonar-1 2023-02-05 04:54:45 UTC
test: Better testing of python IBA functions

Author: Larry Gritz
Author Date: 2023-02-05 00:56:22 UTC

test: Better testing of python IBA functions

Add a shim that can run both the "returns an IB" and "modifies an IB"
version of each IBA function for better test coverage.

dev-2.2 2022-07-01 23:52:51 UTC
Typo

Author: Larry Gritz
Author Date: 2022-07-01 23:52:51 UTC

Typo

110 of 10 results
This repository contains Public information 
Everyone can see this information.