Compiling rules: when should it happen?

Use this forum for general user support and related questions.
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Compiling rules: when should it happen?

Post by B.Y.O.B. »

jensverwiebe wrote: Thu Feb 08, 2018 7:34 pm Remember our discussion when i wanted hdri cached as exr ? ( was also png )
I switched to the save() method because otherwise the ColorSpace settings influenced the saved temp images.
In the commit you linked I now see that we circumvented this problem by changing the Colorspace settings temporarily.
Whatever, I think saving the original format with save() is better. It should solve your problem because every image is now saved with it's original format. We sort of load off the problem to Blender.

So I guess Blender also uses OIIO, tries to save DDS and fails because it's not implemented, so the files are 0 bytes.
We can check for DDS files and use the old method to save a PNG in that case, however it's not high priority for me because I think the number of users using DDS in Blender is very small.
jensverwiebe
Supporting Users
Posts: 141
Joined: Tue Jan 09, 2018 6:48 pm

Re: Compiling rules: when should it happen?

Post by jensverwiebe »

Jep, but a fallback for unsupported imageformats is always welcome.
We cannot await from users to remember which formats can be read or writtten or neither one :mrgreen:
In Blender its more obvious cause unsupported formats are not even listed in the dropdown ;)
Btw: i darkly remember you can use a flag to ignore colorspace, dunno if thats still valid.

Anyway, your idea sounds good else.

Jens
Post Reply