|
aaturner
|
 |
« on: November 18, 2022, 04:01:41 PM » |
|
Good afternoon Mike.
I know that this topic has been exhaustively explored in other threads, most of which I have read and tested the suggested solutions. Nevertheless, I still get the "Image read error" thumbnail on middling to large tiff files (>120Mb - 1.3Gb).
I have tried saving the files as .tiff and .tif, with no, LZW and zip compression - no joy.
I have deleted the files from my print folder and then reloaded them - no joy.
I have exported the files from: a) Affinity Photo v1 & v2, b) On1 Photo Raw 2022 & 2023, c) DxO v5 and from my DAM, Photo Supreme v7 - all to no avail.
I can print the images from the native processing apps, and all thumbnails appear in glorious Tehnicolor (or B&W) when viewed on different viewers, with the exception of FastRawViewer that also shows "corrupt" files.
This is a recent phenomenon for me, as I have been using QIU for years with no major problems; I am presently on v2023.104 and update regularly whenever they become available.
My system is Win 11 Pro build 22621 running on an 11th gen Intel core I7-11700K. I have 32Gb installed memory and a NVIDIA Geforce GTX 1660 graphics card with 24Gb memory.
I'm not sure when this error started rearing its ugly head, but I cannot recall it happening when on Windows 10. I upgraded to Win 11 about a year ago.
I'll appreciate whatever guidance you can give to overcome this glitch.
Many thanks,
Andrew Turner
|
|
|
|
|
Logged
|
|
|
|
|
admin
|
|
« Reply #1 on: November 18, 2022, 06:07:36 PM » |
|
I have a folder here with nothing but super large images. They all build fine and they are all between 1GB and 2GB in size. So the problem is not likely to be with the file size but rather some other "feature" inside the TIFFs. If you post one of the TIFFs that is showing the image read error, I can take a look. You could post on Google Drive for example and post the shareable link here. I will wait for your sample image(s).
Regards,
Mike
|
|
|
|
|
Logged
|
|
|
|
|
|
|
admin
|
|
« Reply #3 on: November 19, 2022, 01:05:48 PM » |
|
Thanks for the files. As I suspected, the issue is not with the file size but the format. There is something wrong with both files. I don't have time to deconstruct the files to find out WHAT the problems are, but I can tell you that not even Photoshop is happy with them. Photoshop opens the A Long Sea Lie in copy-ps.tif file but it throws an error and says it ran into a problem and had to "ignore some data". It does open though. The other file, Leith Hill.tif, won't even load in Photoshop: Photoshop says it ran out of memory. So there is something not right with that one too since I'm pretty sure a 64 bit version of Photoshop didn't run out of memory trying to load it. More likely there was an error in the TIFF formatting that caused PS to loop and run out of RAM.
As for Qimage Ultimate, I didn't get an image read error on either file but the thumbnails look distorted: another hint that there is something wrong with the file format.
Now, what I did do is I opened both images in Affinity Photo (the one program I found which would load both of them) and I exported both as TIFFs without changing anything: a simple resave. Qimage Ultimate built thumbnails and could open those copies no problem!
So I guess I have to ask, how are you saving these TIFFs... because whatever you are using to save them is suspect! Looks to me like your TIFFs are getting damaged on the save.
Regards,
Mike
|
|
|
|
|
Logged
|
|
|
|
|
aaturner
|
|
« Reply #4 on: November 19, 2022, 01:43:18 PM » |
|
Thanks for that, Mike. Hmmm - both files are composites most likely created or modified with Affinity Photo, so I'll go back to the drawing board, follow your approach and save them with no mods.
Thanks
|
|
|
|
|
Logged
|
|
|
|
|
aaturner
|
|
« Reply #5 on: November 19, 2022, 02:31:16 PM » |
|
Reloaded the Affinity Photo v2 native format (.afphoto) and saved as .tiff with no modifications (16 bit); same corrupt result. Loaded the "corrupt" tiff file and resaved as tiff with no mods. This worked in that the image appeared, but the colour profile was not as intended, so not ideal.
At least with your help we have established that the culprit seems to be the save function. Will have to contact Serif to see what is going on. JPG's all save correctly.
Regards
Andrew Turner
|
|
|
|
|
Logged
|
|
|
|
|
aaturner
|
|
« Reply #6 on: November 19, 2022, 05:15:38 PM » |
|
Mike, as a final remark, and to exhaust the permutations that I can think of, I saved my Affinity Photo native files as 8 bit instead of 16 bit .TIFF files, as I will not be doing any more processing. These saved correctly and were accepted with no problem by QIU. The prints between bit depths show no discernible difference to my (ageing) eyes.
Regards
Andrew Turner
|
|
|
|
|
Logged
|
|
|
|
|
JustGeorge
|
|
« Reply #7 on: November 19, 2022, 05:39:23 PM » |
|
Andrew,
This may not apply, or be related to AP v2, I'm still using v1.
Using some plug-ins from within AP has caused issues with the final image, such as the image thumbnail being corrupted or the image doesn't print correctly. In particular, Topaz Studio 2, using either/both the HSL and/or the built-in DeNoise filters causes these problems, so I don't use the DeNoise function in Studio at all anymore, and if I want to use the Studio HSL filter I do that before opening the TIFF in AP. (The HSL filter has a separate slider control for Orange, which I occasionally like to use.)
Generally, I'll do raw conversion in the camera's raw processor (OM Workspace for .ORFs, NX Studio for Nikon raw). Then possibly Topaz DeNoise AI and/or Sharpen AI (Sharpen AI's denoise is sometimes good enough). Topaz Studio if I want to control the orange. Then take it into AP for a few minor tweaks before opening in QU.
A couple of times, running Sharpen AI as an AP plug-in has resulted in the above mentioned problems, in which case I'll just start over with sharpening before opening in AP.
I don't use the original free Nik plug-ins (v1.2.11?) very often, but occasionally they have caused problems, in which case I'll just work around it as well.
I have no clue as to what's going on, and at this point this workflow works for me with AP, and as I said, may have no relevance to your situation.
|
|
|
|
|
Logged
|
~I'm not a photographer, but I play one in real life.~
|
|
|
|
aaturner
|
|
« Reply #8 on: November 19, 2022, 06:42:28 PM » |
|
Hi JustGeorge,
Definitely helpful comments, as I vary my workflow much as you appear to do, using different plugins for different situations. Without going back over each image it's difficult to know just what I have done to which image and with what! I usually do my raw development in DxO v5 and use Nik and/or On1 plugins for other overall fine tuning; compositing work I do in Affinity. I suppose it is too much to expect every developer to test their products against others to ensure that they play nicely with each other!
Much as you already have, I am learning what workarounds work in particular circumstances; a pain in the neck, but it keeps me out of mischief.
Thank you again for your comments.
|
|
|
|
|
Logged
|
|
|
|
|
admin
|
|
« Reply #9 on: November 20, 2022, 11:30:07 AM » |
|
Interesting. I didn't try any mods (plugins) in Affinity. Never would have thought modifying the image would change the file format; they are just pixels in the end! When saving your TIFFs, you could also try to make sure you are not saving layers.
BTW, when I did my test, I saved the TIFF as 16 bits/channel because that's what the original was. Worked fine here. I'm using Affinity 1.10.5.1342.
Regards,
Mike
|
|
|
|
|
Logged
|
|
|
|
|
JustGeorge
|
|
« Reply #10 on: November 20, 2022, 03:02:29 PM » |
|
Interesting. I didn't try any mods (plugins) in Affinity. Never would have thought modifying the image would change the file format; they are just pixels in the end! When saving your TIFFs, you could also try to make sure you are not saving layers.
BTW, when I did my test, I saved the TIFF as 16 bits/channel because that's what the original was. Worked fine here. I'm using Affinity 1.10.5.1342.
Regards,
Mike
In my case, which as I said may not be relevant to Andrew's situation, I've never saved as layers, and almost always as 16-bit. When I'm done with an image I export it as a TIFF, I only have 2 afphoto files on my disk. If I decide to rework an image later, I have the original raw, and there's usually been an upgrade to one of the plugins I use. Although in the case of Topaz, I'm probably at the end of the line in upgrades/updates to the versions I'm using (Studio, DeNoise AI, Sharpen AI, and Adjust AI); Topaz has indicated they're focusing on their new AI products. Anyway, when I go in to re-work an image, it's usually because I've learned something new in the meantime and want to start fresh. So saving/exporting with layers is not an issue. On occasion, I'll use some of the old original Topaz apps as plugins (Lens Effects, B&W Effects, Impression and Texture Effects). I have some old scans of prints and film (35mm & various 120 formats) that were abused in storage, and I try to make the proverbial silk purse out of a sow's ear. And with an apology to Gary Winogrand, I photograph something to find out what it will look like printed. So the issue may not necessarily be with plugins in general, but with specific plugins that may no longer be compatible with AP. But working an image with those apps outside of AP generally don't cause a problem with Qimage. And I have the same version of AP, Mike, which I'm guessing is that last of version 1 from Serif. One thing that is interesting is that while QU will have a hickup with some of these images, other image viewers may not, in particular FastStone and Irfanview. I haven't really looked into that since my goal is to get a print that is acceptable to me via QU and my Pro100. --George |
|
|
|
|
Logged
|
~I'm not a photographer, but I play one in real life.~
|
|
|
|
admin
|
|
« Reply #11 on: November 20, 2022, 08:15:18 PM » |
|
One thing that is interesting is that while QU will have a hickup with some of these images, other image viewers may not, in particular FastStone and Irfanview. I haven't really looked into that since my goal is to get a print that is acceptable to me via QU and my Pro100.
--George
Depends on what each program is trying to do. FastStone and Irfanview are pretty simple programs: they may not care about (or even try to read) some parameters from the TIFF whereas Qimage uses a lot of the embedded info for things like color management, thumb building, metadata sorting, etc. The fact that Photoshop had a problem with both of Andrew's files is pretty telling. Again, Photoshop may not be able to read it but other utilities like Irfanview might be OK because they just discard (or never even read) some of the stuff that is important to Photoshop, Qimage, and other software. Another perfect example of this phenomenon is the old "printer is invalid" error caused by a broken printer driver. Qimage gave a "printer is invalid" error as soon as you start it. Lightroom did not. So people claimed "Must be a Qimage problem". Until... they tried to print from Lightroom. Then they got the same "printer is invalid" error at print time. The difference is, Qimage is a printing program so it reads printer capabilities first thing: it needs those to build the live view, preview page, etc. In Lightoom, printing is an afterthought. So you don't run into the problem until you open their silly print "module" and even then, some parameters (like native PPI, etc.) are not read until you actually click print. Regards, Mike |
|
|
|
|
Logged
|
|
|
|
|
Qimage registration expired? New lifetime licenses are only $59.99!
