I am a bit hesitant jumping in here since I am not fully familiar with the system architecture you are discussing. I did want to mention that it is preferable not to force any conversion to a working space at all - rather allow each image to remain in its initial encoding until/unless it is specifically being rendered for a particular use. Then in that case -- the selection of rendering intent does require some careful logic that depends on the relationship between the image states of the source and destination encodings. Best regards, Ann McCarthy Lexmark CPD Imaging Systems Engineering "Problems can never be solved by using the same pattern of thought which created them." - Einstein <table width=100%> <tr valign=top> <td width=40%>Graeme Gill <graeme@argyllcms.com> Sent by: openicc-bounces@lists.freedesktop.org 10/04/2007 02:21 AM <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>To</div> <td>openicc@lists.freedesktop.org <tr valign=top> <td> <div align=right>cc</div> <td> <tr valign=top> <td> <div align=right>Subject</div> <td>Re: [Openicc] seeking for advice on rendering intent and        black        point compensation</table> <table> <tr valign=top> <td> <td></table> </table> <tt>Craig Ringer wrote: > When you face this sort of user level distinction, it can be worth > having an expandable dialog where a ">>" or whatever button shows > advanced options (and once tabbed open, remembers its state). The > GTK+/GNOME file dialog takes this approach, and while I don't much like > how they did it, the principle is sound. I'm not sure this would be of help in the case, since ultimately we're talking about whether the user is presented with a dialog or not. Some would like to be asked every time an embedded profile mismatches the workings space, some would prefer that the application quietly convert the colorspace. Graeme Gill. _______________________________________________ openicc mailing list openicc@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openicc </tt>