[RFC PATCH 1/6] Add colorcorrection protocol

[Niels Ole Salscheider]

Thank you for all your feedback! I am sorry that I did not respond earlier but 
I was quite busy during the last three days.

> >>> how much data can an ICC profile be?
> >>> 
> >>> I'm wondering whether it makes sense to send it inline in the protocol
> >>> stream like this. E.g. we transmit XKB keymaps by sending only an fd,
> >>> and then reading the actual data from the fd. If the receiver can mmap
> >>> the fd, it could read the data zero-copy, if the profile data in a file
> >>> is the very same, i.e. the sender does not need to transform it.
> >> 
> >> Not sure if that can work in every form of session. E.g. a client side
> >> in memory generated profile might not be visible to the compositor.
> > 
> > Sure it can, just like wl_shm buffers work. Yes, the sender may have to
> > copy from a some malloc'd piece of memory into a mmap'd file, but
> > that's only one copy, compared to the copies with array here: into
> > protocol buffer, socket buffer, receiving socket buffer(?), receiving
> > protocol buffer, and maybe the 5th time into malloc'd memory.
> > 
> >> IMO what would make sense here, is to provide additional information
> >> about identifying the profile (ICC profile ID - a 16byte binary hash or
> >> 32 byte textual) and a mechanism skip or to request the not yet server
> >> cached profile from the client.
> >> 
> >> [That could help clients, which want to show a collection of images each
> >> one colour corrected but most of the images have the same source
> >> profile.]
> > 
> > That would help for cross-client coalescing, sure. OTOH, if
> > transmission is zero-copy, the hashing could be an internal detail of
> > the server and would not need to specify it at the protocol level.
> 
> true
> 
> >>> Also, what if a client has several surfaces all with the same ICC
> >>> profile, would it not be useful to have some notion of re-using an
> >>> already sent and parsed color profile? Otherwise I would imagine lots
> >>> of overhead if every surface has a private copy of the profile
> >>> sent over the wire, parsed, and stored in the compositor's renderer.
> >> 
> >> Agreed, caching is certainly needed on both ends. The question is,
> >> should caching somehow be defined inside the protocol to avoid resending
> >> the same data? I think it would be helpful.
> > 
> > We can do that with just protocol objects, I think. Zoxc in irc had
> > some ideas: https://github.com/Zoxc/weston/blob/cms/protocol/cms.xml
> > wl_color_space object represents a profile.

I agree, it probably makes sense to use protocol objects for profiles.

> >>> Compared to that, I see your protocol adds the option for clients to
> >>> provide a custom ICC profile to the server, and expects the server to
> >>> process it properly.
> >> 
> >> ... a no brainer for compositors.
> > 
> > Somehow when we were talking about color management a long time ago, I
> > understood that there are so many (wrong) ways to implement it, that it
> > is better left for the color-aware clients or libraries to do it
> > properly, so they get exactly what they want. Was that a
> > misunderstanding, or maybe I just remember wrong?
> 
> You remember correctly. Niels solved this by adding a "uncorrected" mode:
> 
> + <enum name="mode">
> + <entry name="srgb" value="0"/>
> + <entry name="blending_space" value="1"/>
> + <entry name="uncorrected" value="2"/>
> + <entry name="profile" value="3"/>
> + </enum>
> 
> That allows expert clients to do *the* right thing, being it profilers,
> advanced colour managed applications with e.g. print simulation
> capabilities etc. without interference of later undesired colour management.

Zoxc did not like the way I handle the "uncorrected" case because it is a bit 
ugly and breaks blending in the uncorrected area. Instead of using a mask to 
opt-out from color management, he suggests to just attach the output color 
space to the surface so that it is converted from output to blending and again 
to the output color space. This however makes it necessary for the client to 
know its output and might cause a loss of precision (which might not be too 
bad in the 16 bit LUT case). What do you think?

Unfortunately, I have not been aware that Zoxc is also working on color 
management before writing these patches. I do not know what his plans are for 
his code but he seems to have some useful patches...

Regards,

Ole