Is there a way to convert images without it changing the color/profile?
For example I select my PNG file -> Convert -> 50%
Then the color changes.
It’s probably removing the color profile. I don’t think we have a way to change that currently.
Ok thanks, damn that was a really useful feature until I double checked this. I usually have to convert quite a lot of highres to lowres images for 3D rendering. The color difference does make a big difference in terms of texture input/render output.
Can I put a feature request in for this?
Would you be able to post an example image we can test with? It'd probably be best to zip it in case the forum software modifies it in some way.
1 Like
I've had a look at that image and it doesn't seem to have any sort of color profile information embedded at all. It's just a normal 8 bit (paletted) PNG image.
Reducing the image to 50% in Opus doesn't seem to affect the (single) color within it either - it remains 130,130,130 as in the source.
The one thing that does change is that the PNG library seems to recognise that only one color is used and so saves the reduced image as a 1 bit (monochrome) image instead. Is it possible that whatever you're loading it into doesn't handle 1 bit images properly?
If you look at the reduced image in Opus do you still see a different color?
I don't know if it's the same case but when I use command Image ROTATE=90 HERE ADDSUFFIX=" rotate" the background turns gray and its size decreases.
png.zip (1.2 MB)
Opus displays the image correctly.
If you claim that the background should be white instead of green then it is a CMYK image, but the actual component identifiers in the file tell it is a YCCK image.
So the error is not in Opus, but in the software you use to write such bogus JPEG images (probably Adobe), and you should complain there.
I have attached a patched image where I changed the component identifiers in the SOF (Start Of Frame) and SOS (Start Of Scan) markers to the CMYK identifiers with a Hex editor. This is a correct CMYK image and it shows a white background.
Regards
Guido
JPEG developer
CMYK_logo_lbn_corrected.zip (482.2 KB)
4 Likes
Thank you for these explanations.
Yes I see what you mean regarding the software interpreting 1 bit images differently. The issue however for me is consistency across all creative apps (3dsmax, blender, substance, adobe etc). I currently have written a script that keeps the bits information the same while resizing images, I was just hoping I could use the built in function in dopus instead (and keep the bit depth the same as the original). My script only works within 3dsmax using maxscript so often I need to resize other files while not in 3D.
When writing PNGs, Opus will use the minimum bit-depth that can hold all the colors, since that can result in a big reduction in file size (and should not make any difference to any program that loads the images; if it does, it's a bug in the other software).
Unfortunately Leo this is not a good solution, since I also work with 16 bit files and when you reduce them to 8 bit you get banding in gradients. Changing the bit depth also has other negative affects, after working in the graphics/IT industry over 20 years I have some experience with this, its not always the application but I understand your point (since I also composite in Nuke, Fusion and other non Adobe products). Retaining the bit depth is important for a creative workflow. For the average user sure, optimization is a great tool, but for Professional use its important to retain the image quality.
For clarity 48 is a 16bit png, 24 is 8bit. Since you also have to consider the alpha.
Thanks! We have a fix for that coming in 13.5.3 beta.
1 Like
It won't affect the content of the image at all. We only reduce the bit depth if the image has 256 or fewer colors and the old bit depth was overkill to represent all of them, in which case we can output a PNG that uses a palette instead of RGBA pixels. It's a completely lossless change in terms of colors.
1 Like
Why did it reduce my 16 bit image to 8 bit and introduce banding in the gradient?
It shouldn’t do that. Can you provide an example image that it happens to? (Please zip it so the forum doesn’t modify it.)
Thanks!
OK, that is 16-bits per channel, rather than per pixel as I was thinking.
Opus doesn't really deal in that, other than that it can load it and convert it to 8bpc. Everything has to be converted to 8bpc in order to display the images at all in Windows, and any conversions done to the file will have that change applied to it first. To convert the file while keeping it 16bpc, you'd need to use something external (e.g. ImageMagick can be integrated into Opus buttons nicely).
Ok thanks Leo.
Currently I'm using Converseen, which does the same thing as dopus but keeps the bit depth. I wanted to get rid of it and just simplify my pipeline using dopus as much as possible for file tasks but it'll do for now lol.