IENT
support openning raw Bayer (as gray YUV400) and CMYK (as RGBA) file
Hi @for13to1 thx for the PR and sorry that I did not find any time to look at this yet. I am not sure about the use of these 2 file extensions thogh:
- Just displaying raw bayer files as black and white pixels is possible, it does not look like the right handling of this sort of input file. Typically this tool will display the result of a conversion to RGB images on screen. So I guess in the case of bayer pattern files the same should happen. But this tool just has no support of that at all.
- Displaying CMYK files as RGBA is not really correct either, is it? Becuase these 2 systems are very different from one another. We would also have to do a conversion to RGB to make this usable in the tool.
Thanks for replying.
I suppose that showing Bayer raw file in gray is OK, because they are actually of one channel 's size, and in the other hand, this is exactly what raw file should look like.
If it show Bayer pattern raw in RGB color normally, it needs algorithm like demosaic etc. There are various versions of demosaic, we have to take its picture quality, resource consumption and something else a lot into consideration. But back to our goal, we just want to see what raw files look like. Intensity is just intensity, it comes before color. So I considered it is OK to show it in a gray manner.
As for CMYK, it comes from printing. For convenience, I treat it as RGBA (they are all of 4 channels), just to observe the original pixel value. Show CMYK file as normal color is absolutely OK, for display, while it has nothing to do with pixel value.
Its transfer relationship is as following (copied from Wikipedia):
R,G,B \in [0,1], C,M,Y,K \in [0,1]
R = (1 - C)(1 - K)
G = (1 - M)(1 - K)
B = (1 - Y)(1 - K)
C = 1 - R / max(R, G, B)
M = 1 - G / max(R, G, B)
Y = 1 - B / max(R, G, B)
K = 1 - max(R, G, B)
I do agree that having something is better then having nothing. So I would like to have much better support for these image types but for now I think I can merge something as you suggested. I will also create some issues to improve the support of these image types. Could you provide me some sample files for these formats? That would be great for future implementation of these.
I do agree that having something is better then having nothing. So I would like to have much better support for these image types but for now I think I can merge something as you suggested. I will also create some issues to improve the support of these image types. Could you provide me some sample files for these formats? That would be great for future implementation of these.
Sure. Thank you for considering this for future implementation.
The zip file below contains the mentioned raw files transferred from the original image kodim19.png:
If by this very PR modification, they will look like this (the CMYK file being treated as RGBA is somehow strange but interesting indeed, haha):