Unable to choose the spectral (coloured) output as an option?
danganbenpa opened this issue · 7 comments
Hi.
I can't figure out to output the spectral/coloured depth maps which are possible with the non-comfyui version of Marigold. I'd prefer to use these if possible because they contain more depth information than greyscale.
I'm unsure if it adds any information really... just another way to present it.
Regardless, added the option with some of the available colormaps, "Spectral" being the default and one originally used.
Actually don't see any difference doing it separately with it's own node, so I moved it there:
Looking closer the data is even 64bit at one point... the colorization actually drops it to 8bit. As an experiment, and because I've wanted this before, I added a node to save images in OpenEXR format, so we can save 32 bit now:
OpenEXR
As I understand it, for Python 3.11.x (win) there is no ready-made OpenEXR .whl file... and with pip I get "ERROR: Failed building wheel for OpenEXR". Sad...
OpenEXR
As I understand it, for Python 3.11.x (win) there is no ready-made OpenEXR .whl file... and with pip I get "ERROR: Failed building wheel for OpenEXR". Sad...
Yes, no official one.. which is why I'm not including it in the requirements currently, looking for a way to better do it. There are unofficial wheels available here that worked for me though: https://www.lfd.uci.edu/~gohlke/pythonlibs/#openexr
OpenCV2 which is used by tons of comfy extensions already so it's likely to just be there is built with OpenEXR support but it has to be enabled via the environment variable
OPENCV_IO_ENABLE_OPENEXR=1 (I think true works as well)
Last I checked because of a small mountain of linked security flaws in OpenEXR. I don't know the status of the flaws or whether they actually matter (these days it could be "loading carefully crafted EXR file continuously combined with local SMM access and UEFI patch allows microarchitectural timing attack to read least significant 16 bits of precision from floating point data on physically adjacent cores at the rate of 0.1 bits per day" and it would be considered a world-ending event. I made that up but it's about as bad as lots of the critical hardware flaws I've seen lately).
See
opencv/opencv#21928
and original bug opencv/opencv#21326
Apparently these have been fixed in OpenEXR but OpenCV won't build against it because they're still using C++98 instead of 11. I don't know why unless some embedded target they have has a compiler ancient enough that it isn't supported.
OpenCV2 which is used by tons of comfy extensions already so it's likely to just be there is built with OpenEXR support but it has to be enabled via the environment variable OPENCV_IO_ENABLE_OPENEXR=1 (I think true works as well) Last I checked because of a small mountain of linked security flaws in OpenEXR. I don't know the status of the flaws or whether they actually matter (these days it could be "loading carefully crafted EXR file continuously combined with local SMM access and UEFI patch allows microarchitectural timing attack to read least significant 16 bits of precision from floating point data on physically adjacent cores at the rate of 0.1 bits per day" and it would be considered a world-ending event. I made that up but it's about as bad as lots of the critical hardware flaws I've seen lately).
See opencv/opencv#21928 and original bug opencv/opencv#21326
Apparently these have been fixed in OpenEXR but OpenCV won't build against it because they're still using C++98 instead of 11. I don't know why unless some embedded target they have has a compiler ancient enough that it isn't supported.
I tried this but despite setting the environment variable, even checking that it's 1, it still refuses to work and complains about the codec... this is on Windows with python venv.
Edit: I think this was actually because other custom nodes import cv2 first, fixed it by using the prestartup script to set the env variable before any cv2 import