Can't edit files


Posting rules: It shouldn't need saying, but... play nice. Please keep your discussions civil. You can disagree, just don't be disagreeable. And, of course, all of the usual stuff like no spamming. Tex adds: I'll be rigorously enforcing this as we go along. We're probably going to be a small community in a little lifeboat, so we can't have members at each others' throats. This is for the sake of the project as a whole. So when you post, pretend you're speaking in person with your very wealthy auntie who has always treated you wonderfully and currently lists you prominently in her will. I won't be tossing anyone out of the forums because we are all in this together (except spammers: immediate membership cancelation), but I'll delete suspect posts right away.


10 posts / 0 new
Last post
rrmunoz
Can't edit files

When I attempt to edit any file (JPG, DNG or TIFF) I get the following error:

Error reading the file
Invalid byte 1 of 1-byte UTF-8 sequence

I'm running the 3.9.2 version on Mac OS 10.6.8.

Any ideas?

Robert

slapp0
Similar to my problem

It sounds very similar to my problem (described in another thread).

I don't have any problem editing the photos, but as soon as I try to save an edited photo in light zone format I get the same error message as you. But I can save the edited photo as for instance .jpg with File:Convert:....

Also I thought that a solution suggested by Kris_W would help, but alas.

But some, not very many though, of my images can be saved in lightzone format. I just can't figure out what the difference is between those that work and those that doesn't.

I tried LZ in 2009 but stopped using it then because of a problem and no help from any support. I am not certain but it might have been the same problem(?).

I wonder if there is anyone who are running LZ on Mac Os X without any glitches? If so I would like to send one of my files to get a confirmation that it is a image file problem or if I should start looking for another type of problem.

tex
I'm putting out an APB on this one

I'll try to get Gens over here to look into it. He's been involved in a move from Spain back to Germany, so I think that's why he's been scarce. But he's a MAC guy with some skills, more than the average MAC user I think.

SFA
The UTF-8 error message seems

The UTF-8 error message seems to be quite a common one according to a quick Google search.

It seems to relate to parsing xml code. When you create an edit file for LZ (as with many other applications these days) it does not edit the image directly but creates a separate edit file - often saved in xml (or a later developement of xml) code format.

I'm no expert but there seem to be some indications in the references returned in my search that in some cases this may be related to different character sets (i.e. different languages) and how those UTF character tables are used or not used by various bits of 'packaged' coding tools.

The problem, therefore, may not be entirely a LZ issue. In fact it likely isn't an LZ issue since there are clearly eople using the software on the different platforms without the problem arising but it's difficult to be certain.

I would guess - and this is a guess - that LZ is expecting the host system to have something insatlled that is not there or not where expected OR LZ's installation has omitted (or some reason inclusing access not allowed) the installation of a required file and is defaulting to a system substitute for it that is not satisfactory foro correct working on the particular machine.

There are some log files created when LZ installs and somewhere in there may be the clues that point to the answers. Or not. However log files take some interpreting - it's very easy to read the words and leap to the wrong understanding.

A line by line comparison of log files form successful and unsuccessfulns on 2 machines running the same (as far as can be expected) Operating System installations might be useful. I'm not sure though. Perhaps someone with Mac exposure could comment?

Grant Perkins

Kris_W
UTF-8 error and related issues

Information I provided previously has not been of much help, so I decided to search the Web. Grant has beaten me to it, but what I have found confirms what he has found and my further comment may be of some use.

My search shows that the issue of a UTF-8 error has been raised as far back as 2007. It was reported that LZ-created or LZ-edited files when opened in other applications caused them to crash. The issue of inability to save or open some files in LZ has been reported in this Forum, so it seems to me the issue works in both directions. Files created elsewhere can have a problem in LZ, files created or edited in LZ cause trouble in other applications. The applications appear to be Java based and the files appear to have contained xml or xmp coded information.

UTF-8 characters can be coded in 1-, 2-, 3-, 4-, 5-, and 6-byte long characters. I understand Java does not use UTF-8 characters longer than 3-bytes long. Can this be the root of the issue?

I have no knowledge of coding nor of Java. I think someone with Java and coding experience is needed to explore this further.

slapp0
Exporting file from Aperture can give LZ reading error

If I export a version from Aperture as a jpg, I get the exact error message Robert had when I open the jpg in LZ.

As both Grant and Kris mention it seems to be known problem since several years.

I was looking at the French LZ web page that somebody posted in this forum. There it seems like this error was reported for Mac some years ago, and POSSIBLY (my french understanding is limited) there was fix/patch released. The link to what I think is a possible fix/patch is not working any more.

slapp0
French LZN site

Here is the url to the web page I referred to above.
http://www.lightzone-fr.com/2010/05/18/correctif-lightzone-pour-aperture...

And this is the actual text
Contacté sur le sujet, le support Lightcrafts nous a fait savoir que le bug était corrigé par une nouvelle mise à jour, que vous trouverez ICI. Remplissez alors les champs requis pour lancer le téléchargement. Lancez ensuite le fichier.Conseil : avant l’installation, fermez LightZone et Aperture

Doug
Non-ASCII characters?

I'm beginning to think that the problem is related to non-ASCII characters used in file paths, file names, metadata, etc. From a log file that slapp0 sent me, there's a Š character in the file path.

I'm thinking that these non-ASCII characters are not being converted to UTF-8 like they should be for XML, and that's what's causing the problem. I've posted something you might want to try on the Issue Tracker. If you do try it, let us know if it helped at all. I'm just making a wild guess at this.

Also, avoiding non-ASCII characters in paths, folder names, file names, and metadata might be a work-around.

slapp0
A quick test - seems to work

Doug

I did a quick test with the changes to the Info.plist file as you suggested.

I managed to edit and save a file from LZ back to a folder with non-ASCII characters in its name. (Previously when saving files in this folder always returned the LZN error message). So the patch worked fine - at least with the first I file I tested.

I can also confirm that renaming the path and the files to only use ASCII characters is a workaround that works. I have tested this with small number of jpgs (which previously failed to save).

Doug
Ooh, I hope that's it

Yay, progress! Or at least, so it seems. Let's see if others have the same result.

If this is the case, it's technically a bug in LightZone. When writing text-handling code in Java, one should be careful to always specify the character set to be used — UTF-8, in this case. But in many places Java provides the ability to ignore that, for the person who's doesn't want to deal with details. In that case, Java uses the "default charset" for the platform: Windows, Mac, Linux, or whatever, and the locale: US, Sweden, or wherever.

My guess is that somewhere in LightZone, it's using the default charset which works fine for Windows or Linux in the US. The change to Info.plist forces the default charset for LightZone to be UTF-8 on that machine.