{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":356369475,"defaultBranch":"master","name":"OpenImageIO","ownerLogin":"imageworks","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2021-04-09T18:49:44.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/320618?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1715748574.0","currentOid":""},"activityList":{"items":[{"before":"feb58ace9e41254091d5ac8e169d0a1420e268ce","after":"ae8aa8f974dbfd3e0bf2d02e0253886582dc952f","ref":"refs/heads/master","pushedAt":"2024-05-22T18:15:30.000Z","pushType":"push","commitsCount":9,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"build: gcc-14 support, testing, CI (#4270)\n\n* Switch runner type for bleeding edge, use gcc14 and python 3.12\r\n\r\n* Various minor gcc-14 + C++20 + Python 3.12 fixes\r\n\r\nNotable: gcc14 warns about std::atomic_load for share_ptr as deprecated,\r\nsince C++20 provides a true atomic shared pointer.\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"build: gcc-14 support, testing, CI (AcademySoftwareFoundation#4270)"}},{"before":"76e9963a7d7e862eaeba7ff1b241d9d70052d59e","after":null,"ref":"refs/heads/lg-tiffdebug2","pushedAt":"2024-05-15T04:49:34.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"}},{"before":"d2f140dc9eb0fcf249afe2bbd53ec97ee680b280","after":"feb58ace9e41254091d5ac8e169d0a1420e268ce","ref":"refs/heads/master","pushedAt":"2024-05-15T04:49:11.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"build: Add CMath target for the sake of static libtiff (#4261)\n\nRecent libtiff versions export cmake configs that, if you built libtiff\r\nas a static library, will reference targets it set up when it built, but\r\nwhich are nonstandard names and won't exist when you build and consume\r\ntheir config exports. Ugh!\r\n\r\nSome can be swept under the rug by turning off some libtiff optional\r\ndependencies, but I can't seem to get rid of a target CMath::CMath that\r\nstatic libtiff target wants. It just points to the math library. So I'm\r\njust setting that up so it will be found when we do the\r\nfind_package(tiff). Oh, the hoops we jump through for badly constructed\r\npackges.\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"build: Add CMath target for the sake of static libtiff (AcademySoftwa…"}},{"before":null,"after":"f53cf1f23f26393cf5bad563cb65a332d7f34ec0","ref":"refs/heads/spi-2.6.1.0","pushedAt":"2024-05-14T23:08:06.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"build: Add CMath target for the sake of static libtiff (#4261)\n\nRecent libtiff versions export cmake configs that, if you built libtiff\r\nas a static library, will reference targets it set up when it built, but\r\nwhich are nonstandard names and won't exist when you build and consume\r\ntheir config exports. Ugh!\r\n\r\nSome can be swept under the rug by turning off some libtiff optional\r\ndependencies, but I can't seem to get rid of a target CMath::CMath that\r\nstatic libtiff target wants. It just points to the math library. So I'm\r\njust setting that up so it will be found when we do the\r\nfind_package(tiff). Oh, the hoops we jump through for badly constructed\r\npackges.\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"build: Add CMath target for the sake of static libtiff (AcademySoftwa…"}},{"before":"d95518ac240f4328d8e3ff2242ccab6e29bfb573","after":"608222ecec0405d05c7cfe40e155ba00b2e2e223","ref":"refs/heads/dev-2.6.1","pushedAt":"2024-05-14T23:07:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"Merge branch 'spi-2.6.1.0' into dev-2.6.1","shortMessageHtmlLink":"Merge branch 'spi-2.6.1.0' into dev-2.6.1"}},{"before":"f53cf1f23f26393cf5bad563cb65a332d7f34ec0","after":"d95518ac240f4328d8e3ff2242ccab6e29bfb573","ref":"refs/heads/dev-2.6.1","pushedAt":"2024-05-14T23:01:30.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"build: Add CMath target for the sake of static libtiff (#4261)\n\nRecent libtiff versions export cmake configs that, if you built libtiff\r\nas a static library, will reference targets it set up when it built, but\r\nwhich are nonstandard names and won't exist when you build and consume\r\ntheir config exports. Ugh!\r\n\r\nSome can be swept under the rug by turning off some libtiff optional\r\ndependencies, but I can't seem to get rid of a target CMath::CMath that\r\nstatic libtiff target wants. It just points to the math library. So I'm\r\njust setting that up so it will be found when we do the\r\nfind_package(tiff). Oh, the hoops we jump through for badly constructed\r\npackges.\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"build: Add CMath target for the sake of static libtiff (AcademySoftwa…"}},{"before":null,"after":"f53cf1f23f26393cf5bad563cb65a332d7f34ec0","ref":"refs/heads/dev-2.6.1","pushedAt":"2024-05-14T22:54:52.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"build: Add CMath target for the sake of static libtiff (#4261)\n\nRecent libtiff versions export cmake configs that, if you built libtiff\r\nas a static library, will reference targets it set up when it built, but\r\nwhich are nonstandard names and won't exist when you build and consume\r\ntheir config exports. Ugh!\r\n\r\nSome can be swept under the rug by turning off some libtiff optional\r\ndependencies, but I can't seem to get rid of a target CMath::CMath that\r\nstatic libtiff target wants. It just points to the math library. So I'm\r\njust setting that up so it will be found when we do the\r\nfind_package(tiff). Oh, the hoops we jump through for badly constructed\r\npackges.\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"build: Add CMath target for the sake of static libtiff (AcademySoftwa…"}},{"before":"676fb5802f2962981b1ae5d1e91503b9bbffa0c6","after":"d2f140dc9eb0fcf249afe2bbd53ec97ee680b280","ref":"refs/heads/master","pushedAt":"2024-05-14T20:43:31.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"refactor: oiiotool break out expression eval methods into separate file (#4256)\n\nThis is just a code move. There no changes to the code logic, though in\r\nthe process, I do change old \"local\" uses of eval_as_bool to the new\r\nStrutil one.\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"refactor: oiiotool break out expression eval methods into separate fi…"}},{"before":"56fcbe13a4daf893435b711b96b71df4bebf5054","after":"372576af5c9a9635ff7b288479c108a3c1c6483b","ref":"refs/heads/spi","pushedAt":"2024-05-14T03:06:00.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"testing: Add new heif test output\n\nSome weird combination of old libheif library gives a different\noiio:OriginalOrientation result. Need this ref because that's\nhow it behaves in that version, but it's not worth tracking down\nbecause it's so old and works fine on newer versions.\n\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"testing: Add new heif test output"}},{"before":null,"after":"56fcbe13a4daf893435b711b96b71df4bebf5054","ref":"refs/heads/spi","pushedAt":"2024-05-14T01:48:35.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"build: Add CMath target for the sake of static libtiff\n\nRecent libtiff versions export cmake configs that, if you built\nlibtiff as a static library, will reference targets it set up when it\nbuilt, but which are nonstandard names and won't exist when you build\nand consume their config exports. Ugh!\n\nSome can be swept under the rug by turning off some libtiff optional\ndependencies, but I can't seem to get rid of a target CMath::CMath\nthat static libtiff target wants. It just points to the math library.\nSo I'm just setting that up so it will be found when we do the\nfind_package(tiff). Oh, the hoops we jump through for badly\nconstructed packges.\n\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"build: Add CMath target for the sake of static libtiff"}},{"before":null,"after":"76e9963a7d7e862eaeba7ff1b241d9d70052d59e","ref":"refs/heads/lg-tiffdebug2","pushedAt":"2024-05-14T01:42:12.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"build: Add CMath target for the sake of static libtiff\n\nRecent libtiff versions export cmake configs that, if you built\nlibtiff as a static library, will reference targets it set up when it\nbuilt, but which are nonstandard names and won't exist when you build\nand consume their config exports. Ugh!\n\nSome can be swept under the rug by turning off some libtiff optional\ndependencies, but I can't seem to get rid of a target CMath::CMath\nthat static libtiff target wants. It just points to the math library.\nSo I'm just setting that up so it will be found when we do the\nfind_package(tiff). Oh, the hoops we jump through for badly\nconstructed packges.\n\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"build: Add CMath target for the sake of static libtiff"}},{"before":"90f78eb5ec17d9a11dea1bcb8826ea61c8eaf669","after":"676fb5802f2962981b1ae5d1e91503b9bbffa0c6","ref":"refs/heads/master","pushedAt":"2024-05-04T15:12:28.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"docs: Fix stray references to the old repo home (#4255)\n\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"docs: Fix stray references to the old repo home (AcademySoftwareFound…"}},{"before":"a6239ead17efb9e07236c834a025e082e89f4de2","after":"90f78eb5ec17d9a11dea1bcb8826ea61c8eaf669","ref":"refs/heads/master","pushedAt":"2024-05-02T00:33:55.000Z","pushType":"push","commitsCount":7,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"CHANGES\n\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"CHANGES"}},{"before":"9073b6c96c457fb98a80baf22b4a59124488d27e","after":"a6239ead17efb9e07236c834a025e082e89f4de2","ref":"refs/heads/master","pushedAt":"2024-04-22T01:18:08.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"fix: Error retrieval safeguards for recycled objects (#4239)\n\nThe recent switch from boost thread_specific_ptr left a bug: if an\r\nImageInput (say) is deleted without the caller clearing its error state,\r\nand then later another ImageInput is allocated and happens to get the\r\nsame address as the first one, it can \"inherit\" the unretrieved error\r\nstate left behind by the other.\r\n\r\nFix by using a unique ID (initialized by an incrementing atomic\r\ncounter) to index the object in the per-thread error store.\r\n\r\nI feel like we still don't have a foolproof replacement for the really\r\nnice lifetime management that thread_specific_ptr was doing for us. One\r\ncould argue that unretrieved errors in an object are a \"bug\" in the\r\nuser's program, but unretrieved bugs currently just accumulate in the\r\nmap, even after the ImageInput is destroyed, until the thread terminates.\r\n\r\n---------\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"fix: Error retrieval safeguards for recycled objects (AcademySoftware…"}},{"before":"f0c89626edc4d603db3c6570eedb2857737fd34b","after":"9073b6c96c457fb98a80baf22b4a59124488d27e","ref":"refs/heads/master","pushedAt":"2024-04-20T22:16:23.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"build!: Move OpenEXR/Imath minimum to 3.1 (#4223)\n\nThese are build-breaking changes that impose a new minimum OpenEXR/Imath\r\nversion supported of 3.1 or higher.\r\n\r\nNeedless to say, this will not be backported to any release branches,\r\nwhich guarantee that they will never raise the minimum supported\r\nversions of any dependencies. This is just for future OIIO. There is\r\nalready a \"developer preview\" branch dev-2.6.1 marking the last spot in\r\nmaster in which the old dependencies are supported.\r\n\r\nFixes #4156\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"build!: Move OpenEXR/Imath minimum to 3.1 (AcademySoftwareFoundation#…"}},{"before":"7f41a6a38308844f39cba941eb597e1cb47c6db0","after":"f0c89626edc4d603db3c6570eedb2857737fd34b","ref":"refs/heads/master","pushedAt":"2024-04-15T23:04:30.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"cleanup: Remove some long-deprecated things (#4234)\n\nThis is just the first step in many for removing deprecated things along\r\nthe way to a 3.0 release. I'm doing a little at a time.\r\n\r\nI believe that here I'm only removing things that (a) have been\r\ndeprecated since 2.0 or earlier, (b) most or maybe all were marked with\r\nOIIO_DEPRECATED and so should have been triggering warnings for a long\r\ntime if used downstream (thus, almost certainly nobody is using it), and\r\n(c) are inline definitions, so this change should not appear to break\r\nlink ABIs.\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"cleanup: Remove some long-deprecated things (AcademySoftwareFoundatio…"}},{"before":"fc5a454a9c26714060e462bbd19b5db8174a353d","after":"7f41a6a38308844f39cba941eb597e1cb47c6db0","ref":"refs/heads/master","pushedAt":"2024-04-13T14:58:16.000Z","pushType":"push","commitsCount":10,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"fix(openexr): Fix out-of-bounds reads when using OpenEXR decreasingY lineOrder. (#4215)\n\nThis change fixes out-of-bounds reads and incorrect scanline ordering\r\nwhen OpenEXR's decreasingY lineOrder mode is used.\r\n\r\nOpenEXR expects to process scanlines in decreasing order when the\r\ndecreasingY lineOrder option is enabled. This change fixes the code that\r\nprovides the chunks of scanlines to OpenEXR so that the proper scanlines\r\nare available when it accesses the FrameBuffer OIIO created. The old\r\ncode was providing incorrect scanlines AND setting up the FrameBuffer\r\nwith incorrect pointers so out-of-bounds reads were occurring.\r\n\r\nThe key things to keep in mind are:\r\n- Chunks of scanlines need to be sent to\r\nOpenEXROutput::write_scanlines() from the bottom of the image to the top\r\nwhen decreasingY is enabled. If the chunk's scanline range does not\r\ncontain the scanlines OpenEXR is expecting to fetch, then it can cause\r\nout-of-bound reads because the wrong information is used to construct\r\nthe pointers for the Slices created when constructing a FrameBuffer.\r\n- OpenEXROutput::write_scanlines() does its own chunking of scanlines\r\nand this logic must also properly start from the bottom of the chunk\r\ndata passed into this function when decreasingY is enabled.\r\n- The to_native_rectangle() call in OpenEXROutput::write_scanlines() may\r\nreturn a pointer to m_scratch if a format conversion is needed. This\r\nmeans the pointers passed to OpenEXR, in this situation, _WILL NOT_ be a\r\nfull frame buffer. This caused OpenEXR to do out-of-bounds reads because\r\nthe computations used to create the Slices were using the wrong scanline\r\nnumber to adjust the pointer.\r\n- The progress callback computation needed to be modified to handle\r\ntraversing scanlines in decreasing order.\r\n\r\nI added an openexr-decreasingY test to verify that the code no longer\r\ncrashes because of the out-of-bound reads and it also verifies that the\r\ndecreasingY images match the increasingY images.\r\n\r\n---------\r\n\r\nSigned-off-by: Aaron Colwell <300262+acolwell@users.noreply.github.com>","shortMessageHtmlLink":"fix(openexr): Fix out-of-bounds reads when using OpenEXR decreasingY …"}},{"before":"cf70e273baffedae47c0c95c8a211b0bf24e20b6","after":"34a9b0754f3ea31ac398e063a7d31a92979503f1","ref":"refs/heads/dev-2.5","pushedAt":"2024-04-02T17:14:34.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"v2.5.10.1 -- because 2.5.10.0 was mis-tagged\n\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"v2.5.10.1 -- because 2.5.10.0 was mis-tagged"}},{"before":"7ae8529cc48be1a34957afab65f9e6c84e5da7d3","after":"cf70e273baffedae47c0c95c8a211b0bf24e20b6","ref":"refs/heads/dev-2.5","pushedAt":"2024-04-02T17:05:35.000Z","pushType":"push","commitsCount":128,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"feat(psd): Add support for 16- and 32-bit Photoshop file reads (#4208)\n\nAs mentioned in #4205, #3900 and\r\nhttps://github.com/AcademySoftwareFoundation/OpenImageIO/discussions/3910#discussioncomment-8913737\r\nOpenImageIO previously did not support reading of 16- and 32-bit files\r\nbeyond their merged image data section. I have now implemented this by:\r\n\r\n1. Adding support for reading layer info from the \"Lr16\" and \"Lr32\"\r\nTagged Blocks as well as adding additional checks to the regular layer\r\ninfo section\r\n2. Implemented the Zip and ZipPrediction compression codec which is\r\nrequired to read these files as that is photoshops preferred compression\r\ncodec for those bitdepths\r\n\r\nDue to the way the Zip data is stored (per channel but not per scanline)\r\nthe current implementation reads the whole channel into a buffer which\r\nis then memcpy'd from by calls to `read_native_scanline()`. The buffer\r\ngets cleared on deletion of the `PSDInput` object\r\n\r\n---------\r\n\r\nSigned-off-by: EmilDohne <86836589+EmilDohne@users.noreply.github.com>\r\nSigned-off-by: Larry Gritz \r\nCo-authored-by: Larry Gritz ","shortMessageHtmlLink":"feat(psd): Add support for 16- and 32-bit Photoshop file reads (Acade…"}},{"before":"2166bba2e8c96f25d1a0993ab2538a4347b10649","after":"fc5a454a9c26714060e462bbd19b5db8174a353d","ref":"refs/heads/master","pushedAt":"2024-04-02T17:05:16.000Z","pushType":"push","commitsCount":12,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"feat(psd): Add support for 16- and 32-bit Photoshop file reads (#4208)\n\nAs mentioned in #4205, #3900 and\r\nhttps://github.com/AcademySoftwareFoundation/OpenImageIO/discussions/3910#discussioncomment-8913737\r\nOpenImageIO previously did not support reading of 16- and 32-bit files\r\nbeyond their merged image data section. I have now implemented this by:\r\n\r\n1. Adding support for reading layer info from the \"Lr16\" and \"Lr32\"\r\nTagged Blocks as well as adding additional checks to the regular layer\r\ninfo section\r\n2. Implemented the Zip and ZipPrediction compression codec which is\r\nrequired to read these files as that is photoshops preferred compression\r\ncodec for those bitdepths\r\n\r\nDue to the way the Zip data is stored (per channel but not per scanline)\r\nthe current implementation reads the whole channel into a buffer which\r\nis then memcpy'd from by calls to `read_native_scanline()`. The buffer\r\ngets cleared on deletion of the `PSDInput` object\r\n\r\n---------\r\n\r\nSigned-off-by: EmilDohne <86836589+EmilDohne@users.noreply.github.com>\r\nSigned-off-by: Larry Gritz \r\nCo-authored-by: Larry Gritz ","shortMessageHtmlLink":"feat(psd): Add support for 16- and 32-bit Photoshop file reads (Acade…"}},{"before":"4dc04a23cb24ea445408a2f7b78173018e04c0e3","after":"2166bba2e8c96f25d1a0993ab2538a4347b10649","ref":"refs/heads/master","pushedAt":"2024-03-25T20:50:32.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"fix: iv build issues with glTexImage3D (#4202)\n\nglTexImage3D not in QOpenGLFunctions but in QOpenGLExtraFunctions\r\nhttps://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4180\r\n\r\nSigned-off-by: ssh4net ","shortMessageHtmlLink":"fix: iv build issues with glTexImage3D (AcademySoftwareFoundation#4202)"}},{"before":"d743c6152d29ca60892921c694f36e34d778a7ce","after":"4dc04a23cb24ea445408a2f7b78173018e04c0e3","ref":"refs/heads/master","pushedAt":"2024-03-24T02:35:42.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"refactor: Make span default ctr and assignment be `= default` (#4198)\n\nMinor simplification. Also add a few `noexcept` in some places that we\r\ndidn't have them already.\r\n\r\n---------\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"refactor: Make span default ctr and assignment be = default (Academ…"}},{"before":"3b9201183632dbb26e153be8d2527615c5d4023d","after":"d743c6152d29ca60892921c694f36e34d778a7ce","ref":"refs/heads/master","pushedAt":"2024-03-23T03:49:26.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"build: make an OpenImageIO_Util_static library and target (#4190)\n\nAdd a `OpenImageIO_BUILD_STATIC_UTIL_LIBRARY` CMake variable that, if\r\nenabled, will build a separately named static version of the\r\nOpenImageIO_Util library, in addition to the dynamic one. It has a\r\nseparate name, libOpenImageIO_Util_static, and a separate exported cmake\r\ntarget, `OpenImgaeIO::OpenImageIO_Util_static.`\r\n\r\nThis can be a help to applications that only need OpenImageIO_Util, and\r\nnot the main OpenImageIO library, and furthermore would prefer a static\r\nlibrary so they don't need a runtime dependency on our dynamic\r\nlibraries.\r\n\r\nCavat emptor: Beware that there are singletons inside ustring, the oiio\r\nthread pool, and possibly others I'm not remembering at the moment. It\r\ncould be a bad thing to have an application that contains both the\r\nstatic and dynamic versions of libOpenImageIO_Util, or to have multiple\r\ncopies of the static library inside the same executable (including\r\ntransitively through dependency libraries that were built\r\nindependently). You have been warned!\r\n\r\nNote also that this is swimming upstream in cmake land. For reasons I\r\nnever quite understood, cmake assumes that a project wants to build\r\neither static or dynamic libraries, but provides little direct support\r\nfor doing both in the same build. So we're taking the matter into our\r\nown hands, perhaps. If somebody thinks the way I'm proposing is very\r\nwrong, please do speak up.\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"build: make an OpenImageIO_Util_static library and target (AcademySof…"}},{"before":"bafee1a67d2574e764014f69036d016a326fe387","after":"3b9201183632dbb26e153be8d2527615c5d4023d","ref":"refs/heads/master","pushedAt":"2024-03-16T16:28:28.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"ci: make one of the Mac tests build for avx2 (#4188)\n\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"ci: make one of the Mac tests build for avx2 (AcademySoftwareFoundati…"}},{"before":"efdeaacc964b02fc0c1d45cffa8e3e0e176e29ce","after":"bafee1a67d2574e764014f69036d016a326fe387","ref":"refs/heads/master","pushedAt":"2024-03-11T03:32:32.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"build(deps): Remove boost from strutil.cpp (#4181)\n\nRemove boost from `Strutil`. Use existing mechanisms and STL features\r\ninstead.\r\n\r\nPartially addresses #4158\r\n\r\nSigned-off-by: Jesse Yurkovich ","shortMessageHtmlLink":"build(deps): Remove boost from strutil.cpp (AcademySoftwareFoundation…"}},{"before":"edb2b4ff870c476b6a31579c9206147c46db7123","after":"efdeaacc964b02fc0c1d45cffa8e3e0e176e29ce","ref":"refs/heads/master","pushedAt":"2024-03-06T22:38:31.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"admin: Add a ROADMAP document (#4161)\n\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"admin: Add a ROADMAP document (AcademySoftwareFoundation#4161)"}},{"before":"c66c56cece8f4fb36f71409dd199997f1b5d7d90","after":"edb2b4ff870c476b6a31579c9206147c46db7123","ref":"refs/heads/master","pushedAt":"2024-03-05T19:53:45.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"feat(oiiotool): Allow decision making about fixnan (#4171)\n\nAdded a new bit of pseudo-metadata that can be retrieved by oiiotool's\r\nexpression substitution: `{TOP.NONFINITE_COUNT}` will be replaced by the\r\ncount of inf and nan values present in the top image.\r\n\r\nAlso, the `-fixnan` command now has the side effect of setting a user\r\nvariable called `NONFINITE_COUNT` to the number of nonfinite values that\r\nwere detected or repaired.\r\n\r\nBetween the two of these, it's now easy to solve the following problem\r\nthat actually came up in production for us.\r\n\r\nSometimes, nans creep into images, and it's easier to repair them than\r\nto fix the complicated process that produced them in the first place.\r\nFor some process in the studio, we had a script that was doing this\r\npreemptively on every image it encountered:\r\n\r\n oiiotool image.exr -fixnan black -o image.exr\r\n\r\nIt was very expensive to repair every image whether it needed it or not,\r\nwhen actually it's only needed once every\r\nmany-thousands-of-images. Most of the expense was in outputting the\r\nrepaired file overtop the original. Now we can do this\r\n\r\noiiotool image.exr -if \"{TOP.NONFINITE_COUNT}\" -fixnan black -o\r\nimage.exr -endif\r\n\r\nIt still has to read the image and look for NaN values, but since there\r\nare almost never any actual NaN's, now for the usual case, it can skip\r\nwriting the output -- which was the vast majority of time.\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"feat(oiiotool): Allow decision making about fixnan (AcademySoftwareFo…"}},{"before":"42f2faa5e3131fdee9813188146ce4d33971be11","after":"c66c56cece8f4fb36f71409dd199997f1b5d7d90","ref":"refs/heads/master","pushedAt":"2024-03-01T18:58:12.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"CHANGES update\n\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"CHANGES update"}},{"before":"92a9b4d8e034742d6c26a48306537ed9c43e0c52","after":"42f2faa5e3131fdee9813188146ce4d33971be11","ref":"refs/heads/master","pushedAt":"2024-03-01T01:03:21.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"cleanup: Belatedly change OIIO_CONSTEXPR14 to constexpr (#4153)\n\nWe've been using C++14 minimum for years, and in fact will move to 17\r\nfor next year's major release.\r\n\r\nAlso use error reporting correctly if a sufficient C++ verion is not\r\nfound\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"cleanup: Belatedly change OIIO_CONSTEXPR14 to constexpr (AcademySoftw…"}},{"before":"372bb8eca379013cc43e2f39b395dcbf4f90e5b7","after":"92a9b4d8e034742d6c26a48306537ed9c43e0c52","ref":"refs/heads/master","pushedAt":"2024-02-20T01:46:23.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"lgritz","name":"Larry Gritz","path":"/lgritz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/504179?s=80&v=4"},"commit":{"message":"fix: Fixes to buildinfo queries (#4150)\n\n* Make sure clang variants are before clang and things that might\r\nemulate gcc are before gcc.\r\n* Use the right symbol for detecting ICC\r\n* Capitalize `__linux__` correctly, oops.\r\n\r\nSigned-off-by: Larry Gritz ","shortMessageHtmlLink":"fix: Fixes to buildinfo queries (AcademySoftwareFoundation#4150)"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"Y3Vyc29yOnYyOpK7MjAyNC0wNS0yMlQxODoxNTozMC4wMDAwMDBazwAAAARRP6Ki","startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wNS0yMlQxODoxNTozMC4wMDAwMDBazwAAAARRP6Ki","endCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wMi0yMFQwMTo0NjoyMy4wMDAwMDBazwAAAAP_MRKN"}},"title":"Activity · imageworks/OpenImageIO"}