3 ms·

Thanks! > In every editor I used, they usually miss YUV support and OpenEXR support (monochannel 16bit images for example). It would also be terribly useful to

Thanks! > In every editor I used, they usually miss YUV support and OpenEXR support (monochannel 16bit images for example). It would also be terribly useful to me to be able to zoom anywhere in the frames and get the precise color values and location of any pixel. From an implementation standpoint, this is not that complicated to implement. I will add it to my todo list, but very likely sometime in the future. I need to know people want this, since it will definitely take a while to implement. Also, it would not play nice with a lot of optimizations I've done so far - but that is a different issue ;) If there's need for it, I'll do it :D > A fast way to open two frames of the same file or of two different files side by side to compare would also be extremely useful! This is also doable. I'm curious why you want this, and how you'd like to visualize the differences. > It is terribly painful to compare two images :) I know :D A looong time ago, I implemented a very advanced zoom on images, so I know :D

somethingsome 6y ago
I do research in imaging, so comparing images generated by algorithms consumes a lot of my time! Side-by-side let me improve my understanding of the algorithms' trade-offs (think for example comparing different compression algorithms, inspecting artifacts). It would also help me debug my codes by comparing pixels values with a reference for example, and many other usages. Of course, those are not the only requirements, but it would already spare me a lot of time to be able to open this kind of format by simply clicking on the file :) The others operations I perform daily are frames' differences (|img1 - img2|) and display them using some colormap. We also frequently need to run several quality metrics like MS-PSNR, SSIM, etc.. to "objectively" evaluate what we see. For the OpenEXR their lib is ok for opening images, I need this because several images I use have only one channel in 16bits, and it's one of the only formats capable of storing this kind of data. While for YUV, the format is actually extremely simple! It's just a big array containing an intensity component (luma) and colors components (chroma) with some upscaling[1] and GPU's decoders can work with them if it's a performance issue [2] ;). Both are standard in the professional video community! Think of them as "raw" video formats. [1] https://stackoverflow.com/questions/60729170/python-opencv-converting-planar-yuv-420-image-to-rgb-yuv-array-format https://stackoverflow.com/questions/60729170/python-opencv-c... [2] https://docs.nvidia.com/drive/drive_os_5.1.6.1L/nvvib_docs/index.html#page/DRIVE_OS_Linux_SDK_Development_Guide/NvMedia/nvmedia_concept_surface.html https://docs.nvidia.com/drive/drive_os_5.1.6.1L/nvvib_docs/i...
- CinematicStudio 6y ago
  Got it, thanks! If lots of people will ask for this, I will certainly implement it. I do understand what you need, and while it's not easy, it's definitely doable. Knowing my already huge todo list, this will take a lower priority. Just in case the above are a "must", and your company is paying, I could set aside 20-40 hours/month to work on this -- as a contractor (I am expensive though :)). Hit me up if you're interested in that.

somethingsome 6y ago

I do research in imaging, so comparing images generated by algorithms consumes a lot of my time! Side-by-side let me improve my understanding of the algorithms' trade-offs (think for example comparing different compression algorithms, inspecting artifacts). It would also help me debug my codes by comparing pixels values with a reference for example, and many other usages. Of course, those are not the only requirements, but it would already spare me a lot of time to be able to open this kind of format by simply clicking on the file :) The others operations I perform daily are frames' differences (|img1 - img2|) and display them using some colormap. We also frequently need to run several quality metrics like MS-PSNR, SSIM, etc.. to "objectively" evaluate what we see. For the OpenEXR their lib is ok for opening images, I need this because several images I use have only one channel in 16bits, and it's one of the only formats capable of storing this kind of data. While for YUV, the format is actually extremely simple! It's just a big array containing an intensity component (luma) and colors components (chroma) with some upscaling[1] and GPU's decoders can work with them if it's a performance issue [2] ;). Both are standard in the professional video community! Think of them as "raw" video formats. [1] https://stackoverflow.com/questions/60729170/python-opencv-converting-planar-yuv-420-image-to-rgb-yuv-array-format https://stackoverflow.com/questions/60729170/python-opencv-c... [2] https://docs.nvidia.com/drive/drive_os_5.1.6.1L/nvvib_docs/index.html#page/DRIVE_OS_Linux_SDK_Development_Guide/NvMedia/nvmedia_concept_surface.html https://docs.nvidia.com/drive/drive_os_5.1.6.1L/nvvib_docs/i...

CinematicStudio 6y ago
Got it, thanks! If lots of people will ask for this, I will certainly implement it. I do understand what you need, and while it's not easy, it's definitely doable. Knowing my already huge todo list, this will take a lower priority. Just in case the above are a "must", and your company is paying, I could set aside 20-40 hours/month to work on this -- as a contractor (I am expensive though :)). Hit me up if you're interested in that.