1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Loxley vs DS Colour Labs

Discussion in 'Digital Image Editing & Printing' started by EightBitTony, Apr 27, 2018.

  1. EightBitTony

    EightBitTony Well-Known Member

    So in my 'I must print more' I've been using Loxley, I'm really happy with the results, the only issue is that postage is quite expensive.

    I got a few test prints from DS Colour Labs, and the blues in both (one sky, one very blue door) are noticeably more green than my Loxley prints, with exactly the same sRGB image submitted to both.

    Anyone compared them both before and found something similar?
     
  2. PeteRob

    PeteRob Well-Known Member

    No , sorry I do my own printing. I'm fascinated by idea of a "more green" blue. I usually have trouble with blues in skies going too magenta or too cyan. I'll see if I can ruin some skies tonight just to find out how it can happen! Do the labs say what printers/paper they are using?
     
  3. dream_police

    dream_police Well-Known Member

    I use DSCL and I never found an issue with them. Last lot I didn't use their profile just a straight JPG and was more than happy. I haven't got anything to compare them with. I'm lucky as I live not too far from DSCL so I collect my prints in person.
     
  4. EightBitTony

    EightBitTony Well-Known Member

    The blues have begun to turn turquoise.

    Loxley is Fujicolor Professional DP II Lustre photographic paper.
    DSCL says Fuji Crystal Archive Paper (I got the test prints in gloss)

    I guess it could be the difference between lustre and gloss?

    This first image, the top is the DSCL, the bottom is the Loxley, and the bottom looks closer to both the monitor image, and my memory of the door.

    2018-04-27 17.56.52.jpg

    The second one, the right hand side is Loxley, the left hand side is DSCL.

    2018-04-27 17.57.21.jpg

    Obviously, these are phone images in terrible light, but I think they show the point?
     
  5. PeteRob

    PeteRob Well-Known Member

    That is quite some difference
     
  6. EightBitTony

    EightBitTony Well-Known Member

    Yeh, the roller door looked okay initially (as we know, colour perception is weird at the best of times), but the landscape didn't look right to me, so I checked against the Loxley prints and then the door looked odd too.
     
  7. PeteRob

    PeteRob Well-Known Member

    I played around in LR using soft-proofing to see if I could turn a sky similar to the Loxley into the DSCL but nothing doing.
     
    EightBitTony likes this.
  8. EightBitTony

    EightBitTony Well-Known Member

    I'm happy sharing an sRGB JPG (full size) with anyone who wants, I quite like the image so not posting a full size copy here. If people want to see if it's Loxley, DSCL or the JPG which are 'out'.
     
  9. Bazarchie

    Bazarchie Well-Known Member

    I use both. Based on my experience I would go with Loxley if I wanted a top notch print, even if it is more expensive, the colours and quality are just better. I have only had one problem with a DSLR product where the picture was noticeable darker than I expected. I had calibrated my screen and used their print profile.
     
    EightBitTony likes this.
  10. GlennH

    GlennH Well-Known Member

    Even within an sRGB profile, it's possible for one printer to produce more green than another.

    It's preferable to be able to convert to the printer profile and send the file straight to the printer without conversion, not least because sRGB clips the native gamut of many lab printers, but also because it's less likely to result in wayward colours. I'm not certain why Loxley doesn't allow it (I'd be interested to know if Adobe RGB yields different results with Loxley than sRGB).
     
  11. Waypoint Charlie

    Waypoint Charlie Active Member

    I've only just come across this thread. I hope I'm not too late to contribute.

    I've been using DS Colour Labs for several years and overall I've been pretty satisfied. However, if you're interested in achieving colour accuracy and are printing on their standard papers (i.e. lustre or glossy) it's essential that you convert your images to their profiles and upload them via the Kiosk (not the web browser uploader).

    Do not use the web uploader for their standard prints. If you do your files will get converted to sRGB, which is not what you want for their standard papers (it is what you want for their 'Fine Art' prints because they require these to be sRGB files). Perhaps they will fix this bug but for now, I'd avoid the web uploader for their standard papers.

    With files uploaded via the Kiosk, the data in the file is what gets sent to the DSCL printer, as is. Even if the file is embedded with a different profile (e.g. sRGB, Adobe RGB) there's no attempt to covert the data to the printer profile. This means if you supply image data profiled for Adobe RGB or sRGB, the colours will turn out wrong, even if you embed the profile to explain what colours the pixel values represent - DSCL don't perform any profile conversion on the data.

    Some people say the difference between sRGB and their profiles is minimal. That may be the case with less saturated colours but with more saturated colours, especially yellows, there are huge differences. Some sRGB colours are out of gamut for the printer profile. Conversely, the printer is capable of reproducing some colours which are outside of the range of sRGB.

    To see the difference, open an image in Photoshop in sRGB working space then Assign (not Convert) the profile to the DSCL printer profile (e.g. lustre or glossy). This shows what happens when you throw sRGB numbers at the printer.

    Below is an example showing the difference between sRGB and the DSCL lustre profile. The lower image, printed with the lustre profile, is correct and is much as I'd see it on my calibrated screen.
    DSCL Profile Test.jpg
     
  12. PeteRob

    PeteRob Well-Known Member

    That sounds the antithesis of colour management.

    The purpose of an embedded profile is to say what colour space standard is being used.

    The purpose of the printer profile is (as far as gamut allows) to ensure that a given (R,G,B) value in the image file is reproduced on paper as the colour defined by the standard.

    When you soft-proof on your computer you are trying to anticipate whether your image contains any areas that are out-of-gamut for the printer.

    When you calibrate(profile) your screen you are making sure that the colour you want on the screen is written to file as the correct (R,G,B) value for the colour space you are using.

    Files without embedded profiles are assumed to be sRGB. If profile information is stripped out, or the reproduction process is not colour managed, the printer will try to reproduce each (R,G,B) value in the file according to the sRGB standard which, if you were using another colour space, will give undesired results.
     
  13. Waypoint Charlie

    Waypoint Charlie Active Member

    I agree entirely PeteRob, and it took me a while to get my head around the way DSCL do things.

    Basically with their standard prints (e.g. lustre and gloss) they don't source colour manage. They assume the data is pre-profiled to their print profile.

    I quite like the system of converting images to their profile. If your monitor has a gamut sufficiently wide to encompass the print gamut then you get a good idea as to how the print will turn out. However, I don't get why they don't source colour manage. If you supply an image pre-profiled to their paper that's great, it doesn't have to be messed with. But if you supply an image embedded with a different profile, why don't they convert it?

    The problem comes with files uploaded via the web browser. The uploader software converts these to sRGB but DSCL still put these into their system without doing any source colour management and processes them as if they're pre-profiled to their papers. It's madness! Perhaps you could prevent the uploader converting to sRGB by tricking it into thinking the file was already profiled to sRGB (either by not embedding a profile or, even worse, embedding a 'fake' sRGB profile). But that makes for awful file management and headaches down the line.

    I can see why many consumer print services only accept sRGB these days, to keep life simple. However, it seems a shame as it means we don't get access to the full depth of colours available with modern print processes.
     
  14. PeteRob

    PeteRob Well-Known Member

    Still doesn't make sense. Unless they mean colour space instead of profile. I don't know how many software packages let you choose a non-standard colour space to work in. Lightroom is fixed. Canon DPP does lets you select from several.
     
  15. EightBitTony

    EightBitTony Well-Known Member

    When my choice is 'send to Loxley get what I saw on the screen' vs 'go through some strange process to help DSCL get a print out in the way I saw it on the screen that varies depending on how I want them to print it', I'm just going to send it to Loxley every time. So far, Loxley, 99% hit rate.
     
  16. Waypoint Charlie

    Waypoint Charlie Active Member

    I'm not sure I understand your distinction between colour space and profile. Doesn't the source profile define the source colour space and how the colour values map into the profile connection space (often L*a*b)? Device profiles are efficient on values (particularly important in 8-bit coding), because they should encompass all the colours a device is capable of handling, without wasting numbers on colours that are out of gamut.

    I'm not familiar with Lightroom but I'm surprised you can't change the working space. With Photoshop CC you can chose to set an RGB working space to any RGB profile, including a monitor profile or printer profile if you wish. It's not the way I'd normally work (preferring to edit in 16-bit ProPhoto RGB), but if you work in a printer profile space it ensures any editing you make stays within the profile/device colour space of that printer.

    As often happens with threads, I fear I'm probably venturing off the original topic!
     
  17. Waypoint Charlie

    Waypoint Charlie Active Member

    I'm inclined to agree Tony, although the colours you view of an sRGB image on an sRGB screen won't look quite the same on the prints (unless the print process covers the full sRGB gamut). The advantage of using DSCL's profiles is you should get a better idea of what you're going to receive. Just their colour management (or lack of it) takes some getting used to!
     
  18. Waypoint Charlie

    Waypoint Charlie Active Member

    Tony, below is DSCL's test image, in sRGB.

    DSCL's lustre can't reproduce the saturation of some of those colours. I doubt Loxley can either, but i may be wrong. I could send you a 7"x5" version which you could add to your next order to test.

    The bottom image is roughly how it would turn out from DSCL. Note the less deeply saturated colours. The advantage of DSCL's profiles is you know this in advance, and can adapt for it.

    monitor_cal_7x5_sRGB_s.jpg

    monitor_cal_7x5_Lustre2sRGB_s.jpg
     
  19. PeteRob

    PeteRob Well-Known Member

    Maybe I have it wrong, but as I understand it the colour space defines the available colours and their encoding. So a given coding is a unique colour in that colour space (it can be a different colour in another colour space). The profile goes between the computer and the output device and translates the coding into whatever is necessary for the output device to reproduce that colour, if it can. That way, as far as is possible, the intended colour can be reproduced on any colour managed device.

    LR works in Prophoto RGB (develop module) then you can save down to a smaller colour space depending on what you do. The only time I do this is to make sRGB thumbnails for Flickr. Otherwise I do my own printing and print directly from LR so I never mess about with saving images for third party printing.
     
  20. Waypoint Charlie

    Waypoint Charlie Active Member

    My understanding of ICC colour management is you have source profiles (i.e. camera/scanner), monitor profiles and output profiles (e.g. printer). These 'characterise' the device i.e. they define what the colour values mean for the device in terms of a ginomous standard reference space or Profile Connection Space (PCS). This is typically L*a*b and is intended to encompass any colour that any device could possibly require. You also have your application working colour space. You usually have a choice of application working space. My thinking is it should be big enough to include all the colours possible in the source and destination space, and the monitor too. So I mostly use ProPhoto RGB in 16-bit mode (in 8-bit mode the steps between each colour value will be rather big).

    When you input a file into your application it uses the source profile to translate values to PCS, then translates from PCS to your application space.

    When your application renders to the screen, it translates from application space to PCS, then uses the monitor profile to translate from PCS to the correct values for display.

    Finally, when your application outputs a file, it translates from application space to PCS, then uses the output profile to translate from PCS to the correct values for output. The output profile may be sRGB, aRGB or could be the printer profile (as required by DSCL for lustre/gloss).

    I'm sure this is a gross over simplification and it may be that 'device-link' profiles get created, to speed things up and cut out the PCS stage.

    Profiles can also define how to translate from one colour space to another (rendering intent), when colours in one colour space are out gamut in another. They can only do this if they are table based profiles and have the right set of A2B and B2A tables. Standard colour spaces, like sRGB, are usually matrix based and don't support colour rendering intents (in spite of the boxes being available in Photoshop, selecting a different renedring intent won't make a jot of difference when converting from one matrix profile to another).

    Sorry folks, I did warn we were going off topic!
     

Share This Page