@cuniek you can still use your own output profiles, as usual. in your specific case, I’d try to convince your photo lab to send you their printer profile so you can soft-proof…
I have their color profiles, I softproof. Everything prints fine when I export to sRGB (I learned that wide gamut is not an option for printing). Still they got random crashes with my files (saved into sRGB). Once I sent them 800 files and poor guy had to open them in Photoshop, and resave, otherwise the printer/lab refused to print them. I tried to nail the problem but I failed (and so the owner of photolab, he said that he never saw anything like that. Filesize was ok, 24bit sRGB, jpeg, all applications open them without any warnings, still random crashes). I was using RT_sRGB in case You ask.
what makes you think it was the profile?
Well, here is what I know:
-When I sent them a tiff file exported into RT_Large_g10, the file was printed allright, but looked exactly the same as when I opened the file without color management. Later it turned out that they support sRGB and AdobeRGB only. So that was my mistake.
-Their Noritsu randomly refuse to print jpeg files saved into RT_sRGB (owner said this was not file specific, few were printed, and then crash. They started printing from last unprinted file - worked fine until anothe crash, and so on). Prints had spot on color and contrast (I was softproofing).
-I saved tiff files into RT_sRGB, opened in Affinity Photo (it shows that the color profile is IEC61966-2.1 sRGB, and does not modify it) and saved into sRGB jpeg. The same behaviour. The only thing inherited from RT is the color profile.
-I saved into RT_sRGB, than Affinity Photo tiff (without colorspace modyfication), and resaved files in RT into RT_sRGB once again - the same problems.
I haven’t had time or strength to experiment more. Maybe this summer.
thanks for the info. you could also try setting the profile from outside RT completely (eg in GIMP) and see if it still crashes… whenever you have time of course
Hmm, the only thing odd about the current RT sRGB profile that I can see, is the 4096-point TRC.
I was going to say that my V2 point curve profiles use 1024 points. But I double-checked to verify after I saw your post, and in fact even though I intended that my profile-making code copy the 1024-point curves from some included “sample V2” profiles in the code folder, somehow that isn’t happening. Instead my V2 profiles have 4096-point curves just like RT profiles.
By the oddest coincidence I got a private email today (just now in fact) specifically asking about those V2 point curves. When it rains, it pours 
. Anyway, I will do my best to fix my code so that the V2 profiles with point curves actually do use the intended 1024-point curves and not 4096-point curves.
Which of course doesn’t guarantee that problems with the printing of your images will be solved by using 1024-point curves. But I’m very grateful to you and also to the person who emailed me about the V2 point curves, for having taken the time to point out this fairly serious problem (well, I think it’s a serious problem) in my V2 profiles.
My apologies! for failing to double-check something so basic as “Are those V2 point curves really 1024-point instead of 4096-point curves”.
@agriggio
Alberto
By default it is LCMS that fixe this value
#define MAX_NODES_IN_CURVE 4097 in cmsgamma.c
jacques
Well, for my V2 profiles I wanted the profiles to functionally match ArgyllCMS V2 profiles that have TRCs that require point curves, which have 1024 points, as do most other older “real V2” sRGB ICC profiles. So my decision to use 1024 points (which now I know doesn’t actually happen with my current profile-making code) wasn’t based on “there are standards” but rather on matching existing “real V2” (as opposed to “V2 according to V4 standards”) profiles.
As far as standards go, there are standards for color spaces, such as the sRGB color space. Then there are V2 and V4 ICC specs for making ICC profiles from the color space specs. I don’t recall if the original V2 specs made any such specification as “this many points”, and I don’t recall any such specification in the V4 specs, but in both cases I think it’s not likely that there is such a restriction embedded in the ICC specs.
Regarding the LCMS point profiles with “more points”, didn’t Marti make that change in response to a discussion with the RT devs? The problem was the accuracy with which LCMS makes conversions between V2 point curves. My recollection is that ArgyllCMS (and perhaps other CMMs besides LCMS) interpolates between the points, whereas LCMS quantizes. For example see this thread:
https://sourceforge.net/p/lcms/mailman/message/31673858/
Also see this somewhat related thread, where the problems (especially evident for channel values near zero) with V4 matrix-to-matrix transforms fortunately were subsequently fixed in LCMS (click on “View entire thread” to view the entire thread):
https://sourceforge.net/p/lcms/mailman/message/32821597/
Another way that the RT sRGB “V2” profile differs from older and ArgylCMS sRGB V2 profiles is in the presence of “unicode” tags. For example, here’s a tag from ArygyllCMS “sRGB.icm” profile (note the MacScript tag isn’t in all of ArgyllCMS profiles):
<textDescriptionType>
<TagSignature>desc</TagSignature>
<ASCII><![CDATA[sRGB IEC61966-2.1 (Equivalent to www.srgb.com 1998 HP profile)]]></ASCII>
<MacScript ScriptCode="0000">735247422049454336313936362D322E3120284571756976616C656E7420746F207777772E737267622E636F6D20313939382048502070726F66696C652900</MacScript>
</textDescriptionType>
And here’s the equivalent tag from RT sRGB profile:
<textDescriptionType>
<TagSignature>desc</TagSignature>
<ASCII><![CDATA[RT_sRGB gamma sRGB(IEC61966 equivalent)]]></ASCII>
<Unicode><![CDATA[RT_sRGB gamma sRGB(IEC61966 equivalent)]]></Unicode>
</textDescriptionType>
And from my own V2 sRGB profile (like RT’s profile and unlike ArgyllCMS profiles), there is the Unicode line:
<textDescriptionType>
<TagSignature>desc</TagSignature>
<ASCII><![CDATA[sRGB-elle-V2-srgbtrc.icc]]></ASCII>
<Unicode><![CDATA[sRGB-elle-V2-srgbtrc.icc]]></Unicode>
</textDescriptionType>
</Tags>
So perhaps the printing place @cuniek uses somehow has V2 software in the pipeline, feeding stuff to the printer, that might stumble over the unicode parts of the RT profile?
But seriously this is just a guessing game as to what causes the Frontier printer to have issues with RT jpegs - what we really need is an example output jpeg from PhotoShop, that was output using the version and the specific color management settings that are used in the establishment with the Frontier printer.
If the Frontier printer only takes sRGB input, I’m curious why the processing pipeline even looks at any embedded ICC profile, as it could just assume the input is sRGB input. Though this would result in truly awful results for non-sRGB files sent to the lab. And if there really is a profile conversion going on from the embedded ICC profile to some other destination ICC profile, why doesn’t the Frontier printer fail on every single jpeg with the RT profile embedded?
Personally I don’t use V2 profiles when doing ICC profile conversions using LCMS or when image editing using LCMS as the CMM. Instead, I make profile conversions using the equivalent V4 profile. If I want a V2 profile in a final output file - such as uploading an sRGB image to the web - then I assign the equivalent V2 profile to the already converted image file, using exiftool, which I’m already using to add copyright and such, so it’s not really an extra step. But obviously my “workaround” is limited to standard matrix RGB output spaces.
I have always old code “LCMS”
** lcms2-24 with “cmsgamma.c” from 10 september 2012.
At this date,
#define MAX_NODES_IN_CURVE 4097
as today
And, if I read code correctly, this value (4096) is used for V2 and V4
I found another version of LCMS from october 2010, and always #define MAX_NODES_IN_CURVE 4097
By searching on the web, I found a version 1.17 from 2007 (just at the beginning of RT by Gabor Horwath), the "define as not the same name but it is the same value
#define MAX_KNOTS 4096
Checking, yes, that’s also in LCMS-2.8 code. But “maximum allowed points in the LCMS code” logically doesn’t entail “must use the maximum allowed points”. Though it seems this is really the case when making point curves using LCMS, unless perhaps this can be overridden using code that says “write exactly this information into this tag”.
Also “maximum allowed points by LCMS code” logically doesn’t mean “maximum allowed points according to the ICC specs”. I hastily read through the V4 specs trying to see if there is any such restriction. The only thing I could find is this:
10.5 curveType The curveType contains a 4-byte count value and a one-dimensional table of 2-byte values. When used the byte assignment shall be as given in Table 34.
Table 34 says:
Actual curve values starting with the zeroth entry and ending with the entry n −1 [encoded using] uInt16Number […] *
So I’m guessing the maximum number of points is determined by what can be held in 2-byte values encoded using uInt16Numbers, which I don’t know, but hopefully someone reading this thread does know.
Anyway, being curious to see what would happen, I just made a linear gamma point curve V2 Rec2020 profile with 8193 points, and both ArgyllCMS xicclu and LCMS transicc had no trouble reading the profile and returning correct results when asked to output LCH values, though I only tried a few values up and down the gray scale. Then I opened a color image in GIMP-2.10-rc1 and converted the image to the 8193-point curve TRC, comparing results to also converting to a V4 parametric linear gamma version of the same profile - identical results were produced, and the resulting image can be exported with the profile embedded, and then reopened from disk.
FWIW, which I’m guessing is not much from any practical point of view .
hmmm… 2^16? 
1 Like
Well, the “count value” would be the number of values. If you have no other specified limitation, the largest possible number would be 2^32=4294967296, assuming unsigned integer…
1 Like
Yes, that seems right. I was totally confusing the 2-byte values with the number of possible entries, and so didn’t even quote the right part of table 34:
Count value specifying the number of entries (n) that follow . . . uInt32Number
So that would be up to 2^32 entries, with a maximum value of 2^16 for each entry - yes? no? Here’s a link to the actual specs:
Doing a search for “count value” will take you directly to table 34. I wonder what the V2 specs say, will try to post later unless someone else does so in the meantime.
That wouldn’t make sense. Vice versa it does make sense.
Edit: scratch my comment. I was confused. Thinking …
1 Like
I’m glad I’m not the only person who has a bit of trouble interpreting what the ICC says!
1 Like
If this is indeed what the spec says, it’s pretty straightforward. I work with specifications like this, and it is clear to me that the largest possible table is 8,589,934,596 bytes, 4,294,967,296 16-bit (2-byte) entries, prepended with a 32-bit (5 byte) count. Yes, not very practical, either storage-wise or processing-wise, but that’s the specified capacity. These days, one doesn’t want to be the person who underspecifies the next IP address, which was thought at the time to have plenty of room with 32 bits…
Edit: Okay just actually downloaded the spec so I could see Table 34, but yep, still the case. There’s just 8 bytes on front of that for the signature and some zeros…
What is the problem ?
- is it my old profile Rt_sRGB that contains a gamma “sRGB”. In this case, is it the gamma that is in question, or the rest of the profile in which I could make a mistake?
- are all V2 profiles generated by LCMS, and in this case, is due to gamma or others ?
- are all V2 and V4 profiles generated by LCMS, and in this case, is due to gamma or others ?
- or is due to other causes, specific printer driver, etc.
If it is 2) or 3) we must verify that LCMS is the cause before intervening with its designer
if it is only 1) it is easy, replace RT_sRGB by the new RT_sRGB-V2-srgbtrc.icc
if it is 4) find the culprit.
Hi @jdc - If your V2 sRGB TRC is a problem, then so is mine as currently my sRGB V2 profile has 4096 points, the same as current RT profiles, and similarly with the presence of unicode tags.
Given that sometimes the jpegs printed, and sometimes not, and lacking a specific example jpeg that wouldn’t print, plus the same jpeg after it was resaved by the Frontier lab’s own copy of PhotoShop, using their specific color management settings, I don’t think it’s possible to troubleshoot “what’s causing the lab to have trouble with the jpegs”.
Maybe it’s not even the profile. For example, maybe it’s in the jpeg compression settings. Leastways I know GIMP has some jpeg compression options that do cause some software to not be able to read the resulting jpeg.
@cuniek - it might be interesting to download ArgyllCMS and replace the RT sRGB profile in jpegs that you’ve already exported from RT, with ArgyllCMS “sRGB.icm”. The “sRGB.icm” profile is in the “ref” folder if you download from argyllcms.com.
An easy way to replace an embedded profile with another embedded profile is to use exiftool. To do this, put the ArgyllCMS “sRGB.icm” in the folder with the jpegs and then type:
exiftool "-icc_profile<=sRGB.icm" *.jpg
Of course experiment with a throw-away jpeg in its own folder, to see if this is working properly, before deploying on a folder full of important jpegs. Also, this is Linux-specific syntax - I don’t know the syntax for other operating systems.
The same exiftool command simply embeds a profile, if there isn’t any already embedded. Otherwise the current profile is replaced.
There is also of course the option of using the ArgyllCMS sRGB.icm profile as the output profile from within RT.
I’d be very curious if using the ArgyllCMS sRGB.icm profile does solve the problem with printing.