Anyone printing with Ubuntu?

[pkr1979]

Hi all,

Im trying to use Ubuntu for my entire photography workflow - which I find can be done until printing. Color management seems to be an issue, and so does printing larger sizes (like A2).

Anyone got a suggestions on this?

Cheers
Peter

 

[ags2mikon]

A couple of years ago I was using virtualbox and win 7 to run Sigma photo pro and printing. Linux is lacking support for some things.

 

[djdister]

I'm using Linux Mint which is based on Ubuntu - and printing using GIMP to an Epson 3880 printer. So far I've made prints up to 13x19 without any issues, using out of the boxc color management in GIMP. I've had to make some adjustments to files which printed well under Windows and Photoshop, but I've been pleasantly surprised so far, but I'm not doing critical color work.

 

[koraks]

Color management seems to be an issue, and so does printing larger sizes (like A2).

What printer are you using, what color management issues do you run into, and from what kind of application(s) are you printing?
This is just to help along the problem-solving process; I currently don't run Linux on my 'daily driver' desktop and only use it for small in-home servers. The only 'printing' I've been doing that involves Linux is 3D printing using OctoPrint... I did experiment with printing from GIMP (on Windows) and found that GIMP's printing support is downright abysmal. Forget about custom paper sizes or even something as simple as being able to correctly position a print on the paper in the first place. I didn't even try doing anything more fancy. Maybe things have improved in 3.0; I've not tried yet.

 

[gary mulder]

Take a modern printer where the color management is done in the printer software. You can upload a custom profile into the printer and just print from the computer without color management.

 

[pkr1979]

I'm using Linux Mint which is based on Ubuntu - and printing using GIMP to an Epson 3880 printer. So far I've made prints up to 13x19 without any issues, using out of the boxc color management in GIMP. I've had to make some adjustments to files which printed well under Windows and Photoshop, but I've been pleasantly surprised so far, but I'm not doing critical color work.

Isnt there an issue uploading 16 bits photos to GIMP - or is that issue solved?

 

[pkr1979]

What printer are you using, what color management issues do you run into, and from what kind of application(s) are you printing?
This is just to help along the problem-solving process; I currently don't run Linux on my 'daily driver' desktop and only use it for small in-home servers. The only 'printing' I've been doing that involves Linux is 3D printing using OctoPrint... I did experiment with printing from GIMP (on Windows) and found that GIMP's printing support is downright abysmal. Forget about custom paper sizes or even something as simple as being able to correctly position a print on the paper in the first place. I didn't even try doing anything more fancy. Maybe things have improved in 3.0; I've not tried yet.

Im using an Epson SC-P 800. Colors aren't right (doesnt look the same as on screen calibrated using Display-Cal). Also, printing A2 is an issue. Ive been printing from ImageViewer and Shotwell. This worked with TurboPrint until recently (TurboPrint is software that makes printing A2 and correct colors possible with the SC-P 800, but after the recent Ubuntu update prints are off center and I will have to purchase a new license to use it again).

 

[pkr1979]

Take a modern printer where the color management is done in the printer software. You can upload a custom profile into the printer and just print from the computer without color management.

Thanks - this sounds like a convenient solution. Does this mean that I could use the color profile i made for my screen, used with my photo editor, with my Epson SC-P 800 and get matching colors? But am I able to control what color profile the printer is using from Ubuntu?

 

[koraks]

Isnt there an issue uploading 16 bits photos to GIMP - or is that issue solved?

I've not been aware of any issues loading 16 bit depth images in GIMP in recent years. What issue are you referring to specifically?

As to the Ubuntu/TurpoPrint etc issue - yeah, that's the kind of thing that made me drop out of Ubuntu some years ago. There would be an update and this would break random stuff, and I'd have to spend hours trying to fix it. I got tired of it and went back to Windows for my desktop environment.

am I able to control what color profile the printer is using from Ubuntu?

The thing is that in @gary mulder 's suggested setup, the printer manages its own profile. You just send srgb to the printer. The printer then handles the rest. I'm not sure whether your printer supports this.
The classic/old-fashioned way is to have the printing application manage the printer's colors by attaching a custom profile. Shotwell AFAIK does not have color management capability. IDK about ImageViewer, but given its primary purpose, I don't expect it's geared to this end.

As to having Ubuntu managing printing profiles directly and then hoping that nothing will get lost in translation between the app you use to print from and the actual printer, I'm not sure, but info like this doesn't make me enthusiastic: https://askubuntu.com/questions/668345/printer-color-management-how-do-i-calibrate-my-printer See also here: https://discuss.pixls.us/t/gutenprint-linux-assigning-icc-profile-for-printer-paper-combo/23876/5 Seems like you'll have to construct custom profiles for your printer & ink & paper & and the printer driver you're using on Ubuntu. In other words, it's apparently 'normal' that ICC profiles supplied by vendors intended for use on e.g. Windows or Mac platforms will not work with open-source drivers.

 

[koraks]

Does this mean that I could use the color profile i made for my screen, used with my photo editor, with my Epson SC-P 800 and get matching colors?

One thing you'll need to understand is that a screen profile has nothing to do with a printer profile. The screen profile is intended to achieve consistency between screens by offering a somewhat standardized output of the innate color data onto a display. The printer profile is intended to offer the same for the combination of printer, printer driver, paper and ink. Therefore, calibrating the screen and calibrating the printer are distinct and separate actions. They are however both required in getting a consistent match between what you see on screen and what you get on paper. So there's no such thing as using a display profile for your printer. If you were to try that, then yes, for sure you'll end up with massive color problems because you're basically working on the assumption that your printer behaves exactly like your monitor. Evidently, this is not the case.

 

[pkr1979]

I've not been aware of any issues loading 16 bit depth images in GIMP in recent years. What issue are you referring to specifically?

If I was uploading a 16 bit tiff file made in PhotoLine to Gimp, Gimp would automatically convert it to 8 bits. You can convert it back to 16 bits, but whats the point. This is some time back - dont know if this is still an issue.

As to having Ubuntu managing printing profiles directly and then hoping that nothing will get lost in translation between the app you use to print from and the actual printer, I'm not sure, but info like this doesn't make me enthusiastic: https://askubuntu.com/questions/668345/printer-color-management-how-do-i-calibrate-my-printer See also here: https://discuss.pixls.us/t/gutenprint-linux-assigning-icc-profile-for-printer-paper-combo/23876/5

Yea - I agree.

 

[pkr1979]

One thing you'll need to understand is that a screen profile has nothing to do with a printer profile. The screen profile is intended to achieve consistency between screens by offering a somewhat standardized output of the innate color data onto a display. The printer profile is intended to offer the same for the combination of printer, printer driver, paper and ink. Therefore, calibrating the screen and calibrating the printer are distinct and separate actions. They are however both required in getting a consistent match between what you see on screen and what you get on paper. So there's no such thing as using a display profile for your printer. If you were to try that, then yes, for sure you'll end up with massive color problems because you're basically working on the assumption that your printer behaves exactly like your monitor. Evidently, this is not the case.

True - thanks.

 

[koraks]

If I was uploading a 16 bit tiff file made in PhotoLine to Gimp, Gimp would automatically convert it to 8 bits. You can convert it back to 16 bits, but whats the point. This is some time back - dont know if this is still an issue.

I think I've read something about that before. However, it's not something I've experienced recently. I routinely make 16 bit TIFF scans and then open them in GIMP. Seems to work OK. I'm using Gimp 3.0 presently. Give it a try; see if the problem is still there.

Hope this helps in any way; I do sympathize with your challenge and I feel this is one of the more challenging problems of the open source approach. In principle, it's really great, but it's so easy to break something and so difficult to try and fix it due to the myriad intricacies involved. I'm afraid the closed-source, captive software community has a massive advantage in this case.

 

[MattKing]

If only the world had a consistent standard to design everything toward - something like C41 film and RA4 paper.....

 

[pkr1979]

If only the world had a consistent standard to design everything toward - something like C41 film and RA4 paper.....

I dream of something like that as well :-D

 

[pkr1979]

I think I've read something about that before. However, it's not something I've experienced recently. I routinely make 16 bit TIFF scans and then open them in GIMP. Seems to work OK. I'm using Gimp 3.0 presently. Give it a try; see if the problem is still there.

Hope this helps in any way; I do sympathize with your challenge and I feel this is one of the more challenging problems of the open source approach. In principle, it's really great, but it's so easy to break something and so difficult to try and fix it due to the myriad intricacies involved. I'm afraid the closed-source, captive software community has a massive advantage in this case.

I agree with you. You end up spending too much time on an issue that is already resolved and available elsewhere. Im probably not trying anything (simply because just one more leads to another, and another, and another), until there is a solution that actually works. I appreciate the feedback though

 

[koraks]

Great; I hope you manage to find a well-documented, plausible workflow that does what you're looking for. I'll be following the search with some interest. The open-source solution still appeals to me.