Images look faded and have false colors

[gyokusai]

Not sure if it’s a bug or if I’m doing something wrong.

I have a lengthy document with numeours images (png with transparencies; all imported, not linked), and for months and months, I worked every day with it until last week, and everything was fine. Today, I opened the document again after about a week, and ca. 90% of the images look “faded,” and some of the remaining colors are all wrong.

I have no idea what’s happened. No files or folder have been moved, renamed, or anything during that week.

[AmberV]

This is something I've recently been looking in to. As far as I know, nothing with Scrivener has changed recently with regards to how images are handled (nor would there be much to change). From what I can tell it's a macOS problem, as I can reproduce the issue in 10.13.4, but not 10.12.6.

The problem appears to be that the color profile is getting stripped from the image. If you right-click and save the image to a file then open it up in Preview with the info palette open, you'll see it is using a "Calibrated RGB Profile", which is from what I can tell a bit of a fallback.

I have had better luck using linked images in 10.13.

[gyokusai]

Thank you, AmberV! That gives me something to think about.

[KB]

Having looked at the issue this is indeed a nasty bug that has been introduced by Apple into macOS 10.13.4. It seems that the standard way of taking an image and saving it as PNG data is now causing the colour profile to be lost and thus the image to be faded. I have reported the bug to Apple along with sample code that shows them how to reproduce the issue (although I doubt they'll fix it any time soon), and I have also found a workaround that *seems* to be working, which entails converting the image to TIFF data first and then saving that to PNG data. That fix will be in the next free update.

All the best,
Keith

[pekak]

I would think that half of the problem is Scrivener rewriting the files. For no apparent reason(?). If the original png files were kept as is, you wouldn't run into this profile saving bug.
Please consider a preference or some other way to keep the graphic files intact. At least the linked image files.

Thanks,
Pekka

[KB]

I would think that half of the problem is Scrivener rewriting the files. For no apparent reason(?). If the original png files were kept as is, you wouldn't run into this profile saving bug.
Please consider a preference or some other way to keep the graphic files intact. At least the linked image files.

Thanks,
Pekka

There is no way of doing this. Scrivener only rewrites the files if you have edited the text of the file it is stored in. At that point, Scrivener's save routines have no idea *what* has been changed, so has to save everything. The save routines only have access to the text and images as they are *now*, and they have to save the images in them accordingly. They have no access to what the original data was and cannot merge that in any way. As I say, though, this is a nasty *Apple* bug, and one that I have found a workaround for in the next update.

[Yaroslav]

have the same annoying issue : ~ (

images are being faded just randomly — please fix this bug!!

[KB]

have the same annoying issue : ~ (

images are being faded just randomly — please fix this bug!!

Did you read the thread above? I already explained that it's an Apple bug that I have worked around - fixed - for the next free update.

[nontroppo]

Hi Keith, do you think the issue here is related: viewtopic.php?f=2&t=51793

The PNGs are growing in size during compile, which with lots of PNGs causes a large increase in the final EPub size. Perhaps this colorspace metadata element is causing this?

[KB]

Hi Keith, do you think the issue here is related: http://literatureandlatte.com/forum/vie ... =2&t=51793

The PNGs are growing in size during compile, which with lots of PNGs causes a large increase in the final EPub size. Perhaps this colorspace metadata element is causing this?

No, I doubt the issues are related.

[AmberV]

If anything this bug would cause a slight drop in image size, as from all indications it appears the colour profile is being dropped. But even if one were being added or modified, it would take a lot of metadata to bloat a graphic from 200 to 800kb. That’s a lot of text. More likely it’s what I pointed out—these images if you look at them up close are not as simple as they look at the target size, they are dappled with dithering and that is very complex from a compression standpoint.

[pekak]

Scrivener's save routines have no idea *what* has been changed, so has to save everything

Gotcha.

For my purpose (which is to produce tex) I can get a working solution by deselecting Markup -> Export images in compile settings. Images can be kept in subfolder and linked into Scrivener. Then with Markup -> Replace images with text, the image folder path can be included. Images show both in Scrivener and (externally) typeset pdf files.

I can use a couple of styles and use style-replacement to insert tex layout settings so image is sized as needed (full width, margin image etc). This is with AmberV's LaTex-template.

I also need to keep linked images as is and not resize them in Scrivener, as the program considers it ok to modify original linked images (which I oppose on principle): Manual 15.6,4 Linked Images: ... "It is important to know that doing so |resizing] will alter the original image’s meta-data on the disk."

So I can't copy/paste images or resize them in-app. I can live with that. I think I'll keep doing this even when image profile bug is fixed.

--
Pekka

[KB]

Gotcha.

For my purpose (which is to produce tex) I can get a working solution by deselecting Markup -> Export images in compile settings. Images can be kept in subfolder and linked into Scrivener. Then with Markup -> Replace images with text, the image folder path can be included. Images show both in Scrivener and (externally) typeset pdf files.

I can use a couple of styles and use style-replacement to insert tex layout settings so image is sized as needed (full width, margin image etc). This is with AmberV's LaTex-template.

I also need to keep linked images as is and not resize them in Scrivener, as the program considers it ok to modify original linked images (which I oppose on principle): Manual 15.6,4 Linked Images: ... "It is important to know that doing so |resizing] will alter the original image’s meta-data on the disk."

So I can't copy/paste images or resize them in-app. I can live with that. I think I'll keep doing this even when image profile bug is fixed.

--
Pekka

I'm glad you have a working solution - I do hope to push out this fix fairly soon, though.

Also, it turns out that I was wrong in one respect. Although Scrivener doesn't have any idea over the image data that is mostly handled by the text system, there is one circumstance where this isn't true: if, upon loading a document, Scrivener finds that an image isn't the size encoded in the RTF, it resizes the image, which will change the data using Apple's standard PNG encoding methods. And there is currently a bug whereby rounding errors cause this to happen to most images (because applying a scale may, for instance, say the image width should be 400.39999 pt when the image is actually 400.42 pt wide, in which case there is no need to resize and re-encode the image which is currently happening). So this otherwise minor bug in Scrivener - something that has never had a negative effect or been obvious in the past - means that Apple's colour fading bug is affect existing images in Scrivener rather than just ones that are resized. I've fixed this bug as well as worked around Apple's bug for 3.0.3.

Meanwhile Apple has closed my bug report to them as a duplicate, meaning that other coders have reported it too.

All the best,
Keith

[lada93]

TIFF workaround not working for me. The pics were mostly screenshots or taken off the internet, I no longer have any of the files. Any chance this future fix will 'revert' the colour pattern of the affected images back to normal, or should I start hunting for the originals now to replace them? heh

______
Scriv 3.0.2
MacOs 10.13.4

[KB]

Unfortunately if you've edited the text so that it gets resized, the image data is changed, so you will need the original. Sorry for the inconvenience. We are hoping to get the fix out this week, next at the latest.

All the best,
Keith