So there is a common misconception (on Fstoppers) that PNG is not color-managed. I always heard that.
@Elle - This is now fixed. You can upload your PNG files and they should stay as is.
Here is your file to test:
Hi @patdavid - according to exiftool, that’s actually a grayscale image that has an RGB ICC profile embedded - I removed some parts of the exiftool output to make it easier to see the relevant parts:
$ exiftool *16b96.png
ExifTool Version Number : 10.63
File Name : 55a2dd8ee55a4b02f9c0169ce93d80243fe16b96.png
Directory : .
File Size : 1695 kB
File Type Extension : png
MIME Type : image/png
Image Width : 1200
Image Height : 1200
Bit Depth : 16
Color Type : Grayscale
Profile Name : ICC profile
Profile CMM Type : lcms
Profile Version : 2.2.0
Profile Class : Display Device Profile
Color Space Data : RGB
Profile Connection Space : XYZ
Profile Copyright : Copyright 2016, Elle Stone (http://ninedegreesbelow.com/), CC-BY-SA 3.0 Unported (https://creativecommons.org/licenses/by-sa/3.0/legalcode).
Media White Point : 0.95045 1 1.08905
Media Black Point : 0 0 0
Red Matrix Column : 0.67349 0.27904 -0.00194
Green Matrix Column : 0.16566 0.67535 0.02998
Blue Matrix Column : 0.12505 0.04561 0.79686
Red Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract)
Green Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract)
Blue Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract)
Profile Description : Rec2020-elle-V2-g10.icc
Image Size : 1200x1200
Megapixels : 1.4
Opening the downloaded file in GIMP-2.9, GIMP identified it as a grayscale image, discarded the embedded RGB ICC profile, and assigned the GIMP built-in grayscale profile. Assigning a linear gamma profile from disk does restore the proper tonality.
I wonder if that is related to another change pat and me did for discuss a while ago.
Actually it seems imagemagick is fucking us over … and the way to fix it depends on wether you do jpeg or png 
Hmm.
Ok, here’s what I’ve learned today:
- If all three channels of an image are identical, imagemagick will automatically set the colorspace to
grayscale.
a. If it’s a jpeg, to fix this, set-define colorspace:auto-grayscale=off
b. If it’s a PNG, set the output file toPNG24:outfile.png
For example, on Imagemagick 6.9.5-7 Q16:
$ convert.exe linear-rec2020-radial-smooth-gradients.png test.png
convert: profile 'icc': 'RGB ': RGB color space not permitted on grayscale PNG 'test.png' @ warning/png.c/MagickPNGWarningHandler/1656.
- The logic to manage this edge case severely complicates the forum image handling code.
The solution
If you need to use weird colorspaces or custom profiles, then zip/tar/bzip the file up and upload that. Then you can be assured the file will transfer as-is.
Other images you want people to see should all work fine, even in sRGB, AdobeRGB or some other colorspace (that is, our patch from last year should have fixed the colorspace getting nuked).
OK, my apologies, but I don’t know what a weird color space or custom profile is. Could you be more specific?
If it helps, to convince ImageMagick to behave itself with RGB pngs in which R=G=B everywhere, the png equivalent to "-type TrueColor " is “-define png:color-type=2”.
We could program all those things into the resize function. But the code wouldn’t be beautiful anymore. As you have to use different options for different fileformats to tell imagemagick not to do any conversion other than “resize”.
And somehow he didn’t like my suggestion to only allow one fileformat. 
Are you being purposefully obtuse? How about outside the support of browsers? 
Or you can just use PNG24:outfile.png as I noted. Either way it’ll keep the colorspace as desired, which is good! 
Good policy to follow. How about HEIF support? 
I think someone mentioned something about being able to directly upload a file to pixls instead of to someplace on the web - does this mean there is a way to upload a file from one’s own computer to somewhere on the pixls website?, somewhat like bugzilla allows to upload files by navigating to one’s local copy of the file? If so, what’s the procedure? Is there a help page somewhere?
-
If it’s in the context of a threaded discussion here, the best option is to zip the file up and attach it to a post.
-
If it’s a resource for wider consumption you can also add it to the github org. (Not sure which repo to use for something like this yet, but we can figure something out)
-
If it’s not appropriate for git, we can also add it to the files section of the site (I’d have to dig up the credentials for posting it, but if you want it I’ll grab it for you).
That’s the question. After the file is zipped up, what is the next step? Upload it to the web and provide a link? Or is there a way to navigate to the file on one’s own computer and upload it directly from the computer?
1 Like
Oh for the love of pete. You ever get doing so many things at once you screw up some of them? That’s me right now. I’m sorry (in my head it sounds simple, but I’m not being clear).
You can upload the file right here in the forum - just upload directly to your post using the upload button:
Or you can just drag and drop from your machine into your post composer.
I apologize for spacing out!
I was being silly too. I removed my other post because I thought @patdavid had answered your question. Just drag and drop into the post editor. Proof:
dragndrop.zip (124 Bytes)
1 Like
Possibly, sometimes I can’t tell . But which browsers? And what does “support” mean? Clearly Firefox “supports” linear gamma RGB matrix profiles, but the images don’t display properly in the shadows. But just about all RGB matrix profiles with more or less perceptually uniform TRCs do display properly, assuming the right choices are made in about:config.
I’m fairly sure that Firefox supports some LUT profiles, but not others, perhaps LUT profiles with the XZY Profile Connection Space are not supported? I think that’s correct, but it’s been a long time since I last checked.
And what about V2 vs V4? Firefox only supports V4 profiles if the right switches are set in about:config.
Are AdobeRGB-so-called-compatible profiles made using the default LCMS D65 white point and not compensating for hexadecimal rounding “weird” or “not weird”, “custom” or “not custom”? They don’t match Adobe’s actual specifications, and they aren’t 100% well-behaved, which is one of the defining criteria for an RGB working space. But these are the types of "AdobeRGB-compatible profiles distributed by most free/libre profile makers.
OK, cutting to the chase, I’m guessing that by “not weird” and “not custom” you might mean “more or less closely approximating the actual profile specs for sRGB or AdobeRGB ICC profiles, including the specfied more or less perceptually uniform TRCs”.
But that does leave to one side the issue of V2 vs V4, and also the issue of actual browser support, so perhaps really the only profiles that aren’t weird or custom are V2 sRGB profiles?
- Take the top 4-5 browsers in use, in their default configurations.
- Check their color management capability.
- Cross-correlate the results to arrive at a color profile supported by all.
There you have it. My initial guess would be sRGB v2, but you’re far more of a color expert than I am.
Adapt for the least-available that provides the ability to support the largest segment of your audience if at all possible. This is just being cognizant of the media used to share images (in this case a browser that you can’t know which one it is, on a web forum). You decide how you want to share your images. 
Well, of course V2 sRGB is the lowest common denominator, and that’s the color space I always recommend for anyone sharing images on the web unless they know the intended audience is equipped to properly view larger and/or V4 color spaces on properly calibrated and profiled monitors using properly color-managed browsers.
Which is to say, almost no-one except maybe people who participate on photography forums, and even then a lot of people won’t meet all the listed “unless” caveats. I don’t meet all the caveats because my monitor’s color gamut barely exceeds sRGB, though I can see a nice swath of greens and blue-greens that fall outside the sRGB color gamut.
But the specific request was made that I supply a test image that can be used to check whether image viewers can properly display linear gamma images. So I supplied two linear gamma 16-bit images, both pngs, both images had R=G=B everywhere. One image uploaded without any problems, the other was resized, converted to an 8-bit jpeg, and also converted to a RawTherapee version of sRGB, which left people asking the natural questions “Are you sure you uploaded a png? Are you sure the image isn’t already posterized?” And so on.
Supplying these two test images took a fair amount of time and thought to figure out what actually would constitute proper test images, and then to prepare them and upload them. I appreciate the fact that @patdavid has taken the time to investigate what went wrong and how to fix the problem, which apparently can’t be fixed. So that’s good to know. In the future I’ll provide zip files.
A bit off-topic: concerning file types. What is the purpose of accepting certain ones and not others? I am sure that whatever is on the white list is something that the back end knows how to handle and also should be able to remove unknown embedded tags or code that could potentially be malicious. However, the acceptance of archives like zip might still present a risk depending on what people place inside of them. Just thinking out loud. I know nothing about this stuff .
PS I guess another reason from the top of my mind would be to prevent irrelevant file formats from clogging up the forums.