Mon, Feb 24
More than a week without reply or activity.
Due to the policy of the tracker closing for until required info/data are provided.
Thu, Feb 20
Tested and it's still an issue, although since this report 'BILINEAR' needs to be passed to redo this error.
Mon, Feb 17
Have confirmed was issue with the test image file - hadn't realised that the oiiotool had generated the image with incorrectly labelled channels. Thanks.
Fri, Feb 14
Thu, Feb 13
This channel layout is nonsensical, how to interpret it is probably not defined anywhere.
File rgba.exr opened in gimp has no alpha channel, in krita it does.
Not working in 2.79 as well
Natron doesnt recognize the Y.Y channel as Alpha by default either...
For this EXR rgba.exr blender as a whole doesnt seem to be able to read alpha. (not sure yet whether this is correct or not)
The image contains pixels with zero alpha and non-zero color channels. Krita has modified those pixels to have at least some alpha. The initial values will not be reverted on saving the image back.
@Ben (Neb55) : I have updated the task description, could you please check if
is still unreadable in other apps for you?
Wed, Feb 12
Please provide concise steps to reproduce the issue. Based on the current description I have to guess what I have to do to reproduce it, and I'll probably guess wrong.
This is more or less a known thing, will add as TODO to T72390: Improve UDIM functionality
Tue, Feb 11
I can't reproduce this in current master (be8879718e24e417d299eb298b8a9d4d2ca324ee), even with WITH_COMPILER_ASAN. @Campbell Barton (campbellbarton) is this still an issue?
Mon, Feb 10
Hm, this still being an issue, but one that has no apparent/obvious solution yet (talking about the Y in XYZ), I am kind of unsure how to classify this report...
Sun, Feb 9
Can reproduce in blender-2.83-6fff73e3f001-windows64 There's a D6786: VSE: Refactor proxy loading diff that fixes this, will confirm for now...
Fri, Feb 7
Mon, Feb 3
My first guess would be that there is still a lock on the image buffer when using the Copy Option. Looking more into the operation it selects the copy by default for rendered images. But users can still change it afterwards. As rendered images don't have a filepath we might want to hide the copy option from the user interface as it always needs to be ticked? We should discuss this with the UI/UX team as the solution might just be to hide the Copy option in the UI.
Thu, Jan 30
Jan 27 2020
Jan 24 2020
Still problem with JokerGargle_Displacement.exr
Jan 23 2020
Thanks for the reply.
Either developers don't have time or are not aware of this issue or don't consider it significant enough to put what they are currently doing to the side and work on this issue.
Personally I am aware, but don't have time currently
What's the point of not fixing this given the solution is found? Doesn't FFmpeg API allow flags like command line version?
Thousands of people render ffmpegs every day not suspecting the colors get screwed, and those that do probably think (as I did before), that ffmpeg is just not good for anything and have to reseort to external converters.
Jan 22 2020
Jan 21 2020
I can not remember If I was looking into this, but I can not reproduce this issue anymore.
Jan 20 2020
Unable to reproduce anymore. As this is an old image I am closing it.
I was also able to open the file back in the image editor.