Lightzone automatically upscales to original size after cropping - Bug or intention?

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.

15 posts / 0 new
Last post
Lightzone automatically upscales to original size after cropping - Bug or intention?

Hello all and devs:

I'm currently using Beta14 x64 on Windows 7 64bit. I think this may be general behaviour of the programme rather than specifically beta-related. Still, I'm putting it here, maybe it can be added to beta bugs.  It may be windows (registry) related, I haven't tested this on Linux.


I have a problem concerning the automatic saving routine Lightzone uses when simply hitting "Done". I have the resize option set to "Don't limit".

* I open a RAW file from a Canon 650 and apply some changes. The pixel resolution there is 4290x2856

*Then I align via free rotation and crop out a 1:1 crop region from the centre, with, let's say, about 60-70% of the short edge length

*When I hit Done, the jpg is saved with a side length of 2846 pixels, which is clearly too large. It is also unimportant exactly how large the crop is - the saved jpg is always 2846x2846.


I looked over the registry today for the other memory bug, and I found this exact size in the "Save" string of the Lightzone settings, as the following:

<com.lightcrafts.image.export./Original/Height/Option value=\"2846\"\\>/u000d/u000a

<com.lightcrafts.image.export./Resize/Height/Option value=\"2846\"\\>/u000d/u000a


So it obviously always applies the value stored as the original height. I would assume the same also happens when just rotating, which naturally also applies a crop.

I'm using LZ to batch edit some photos for scientific documentation, where all the excellent contrast enhancement methods in LZ are of paramount importance. I also need it for then quickly aligning/rotating and cropping, which I haven't found so easily available in any other (free) single solution. So I like everything up until the final saving step, but I would very much like to not upsample my crop, and rather just save 1:1 pixels - if at all possible.

So, is there a way to avoid this?

As a further wishlist item it would be very nice to put in the actual pixel size of the cropping box, and maintain it during rotation.


Do you get the correct size if you convert/export your _lzn.jpg files?






And I think you should upgrade to the latest version, v4.1.0~rc1, before spending additional time on tests.


Good night!


RC1 update

Ok, I've installed RC1 and performed the following tests:

Took one of the previously cropped images and used Convert to resize to 1950x1950 pixels and save a copy. The resulting image is 1951x1951 pixels. So far so good.

Then I did what I did before: Used the normal crop function again, moved the crop around a bit, and hit done. The resulting image is again 2846x2846 pixels, resulting in upscaling of the original pixels.

The only way to not get 2846 pixels is by not fixing the 1x1 crop window, then only one side will be fixed at 2846.

Now all of this wouldn't be a problem if I didn't need to at least rotate. I can crop without upscaling in Irfanview or some other programme. But once I rotate I'm getting an upscaled image.


It does look like this was the desired behaviour, though.

Might be a kind of a bug

Two days ago I was able to reproduce your problem, but after some fiddling I have lost this “ability”. I was in a hurry, but I remember I only did two things:


- before saving, I chose 1:1 (100 %) view of tiny cropped and rotated square image, since it was up-scaled in editor to fill the available window space;
- in Preferences, I switched from Don't limit to Fit within 1024×1024 and back to Don't limit


Something was reset, so I still can't reproduce the problem any more.


I most often use the JPEG-LZN full-sized images as my final output, but by design this are “sidecar” files, containing editing information plus a preview image. (I believe in old LZ versions the sidecars were text-only *.lzn files, preview jpgs being added later as an improvement.) Default setting of JPEG-LZN images is 1024×1024 and you are supposed to “convert” them to get the final result. Still, this looks like a bug, even the preview image should not be up-scaled, I think.

I didn't look at registry changes, since it is almost morning here.


Have a nice day!



Ok, but this means going to 1

Ok, but this means going to 1:1 and then doing what you did should make this upscaling go away? Maybe I should just try going to 1:1 and then hitting done.

I don't quite get the sidecar files thing. So the jpegs that are generated when you hit "done" aren't meant to be used as final versions?


EDIT: Hmm... NOW I can't get the saved jpgs to change size at all! I still always get this fixed size, even when I set it to "Limit to 1024". I think my settings got messed up somehow. Will reset and then see what happens.


Yes, hitting "done" generates

Yes, hitting "done" generates a sidecar *_lzn.jpg file that is not meant to be the final version (although it can be used that way). Since you set the size to "Limit to 1024", this is the maximum size of generated *_lzn.jpg files. You get the final, properly sized version by "converting" the *_lzn.jpg file.


By the way, I found that the problem with up-scaled cropped images also happens in Linux version of LightZone.



Mart is correect that at one

Mart is correect that at one time there were separate files for the edit instructions and the Previews. Combining both into a single file made the folders less cluttered and gave a number of other advantages in terms of file management and, potentially, making the edit file act also as the final output.


I think in part that was to to do with ole time limits ot the number of files one might have in a folder .... or something like that.


The upscaled cropped image is an interesting logical challenge (the seemingly off sizes for the rotated versions seem to be just the pre-calculations of the largest size that will fit within the image space using the selected ratio and amouunt of rotation).


The thing is once one has elected to use Don't Limit the only logical constraint that one can derive from the RATIO  is either from the original file sizes or the max sizes possible post rotation. For the purpose of a Preview/Thumbnail "Don't limit' may not seem very logical - but then neither would any of the other options really, especially if significantly different amounts of cropping had been applied or significantly different sizes of original files from different cameras.


"Done" is meant to be a quick and simple save. "Convert" has a bit more processing involved wiht a number of selections and so will present the available image size based on the crop. It also allows, inter alia, for resizing the image up or down.


Using the saved _lzn file as a final output, as Mart does, is fine if one is happy with the results and the save/done approach gives a resolution that suits the needs. However that is not really the intended "best practise" in spite of the fact that it will work well enough if you no what you are doing with it.


I'm not really sure what you could do with "Save/Done" to keep it simple and fast according to its purpose and yet build in some form of "intelligence" that might guess the real requirements of the user. You couold make it like "Convert"  .... but then "Done" would be redundant and, presumably, not fast.


I go for the original Lightcrafts recommendation  - keep the files small. So I set everything to fit within 1024x1024. I think it would be a rare thing to crop much smaller than that (and still get a usable image from a Convert!) so it's fine for its intended Preview browser purposes.


I suspect that "Don't Limit" was included when cameras developed to the point that images might exceed the fixed sizes offered (based on typical monitor resolutions of the day) and was made available to allow people to have large (uncropped) images instantly available to load as jpgs rather than have to calculate them form an original and edit file each time. In other words purely for faster initial display performance as systems gained larger capcity disks but not necessarily higher performance internals.


So I guess it's not really a bug  - it's doing what is intended. Whether it is logical can be debated. What the alternative logic might be could be an interesting discussion.  I'm not sure that the subject would be high on my "Ways to improve LightZone" list. Personally I would "fix" it by removing the "Unlimited" option and avoiding (some) confusion. I would understand if some thought that might not be ideal - but it's not like there are no alternatives to getting the final output required.


My half cent worth.







Well, right now when I save

Well, right now when I save an image with "Done", at least on those previously generated images I've been dealing with so far, setting the "Limit to" dialog in the preferences has no effect whatsoever. I can limit it to anything, but the image in the sidecar file always has this 2846 dimension. This wasn't always like this, I used to get resized images just from hitting "Done". I HAVE reset the preferences, and it still does it.

What I still have to try is using a completely new image, so far untouched by LZ. Maybe once the sidecar with this 2846 resolution exists it contains some information that limits changing the size of the preview image?

Yes, if I remember correctly,

Yes, if I remember correctly, changing the size setting doesn't affect the already edited images, unless you create a completely new version (from the source image, not just saving the resulting lzn image as a new version). With a virgo intacta image it should work as desired.


Beside resetting the preferences it is sometimes useful to clear the cache. And I have auto save disabled. Not that this helps you in any way, I know.

Ok, so... Do we agree that it

Ok, so... Do we agree that it's a bug? And will this be added to some sort of official bug list?

You can add this to official

You can add this to official bug list on GitHub.

Ok I will, ASAP.

Ok I will, ASAP.

See my post in response to

See my post in response to Mart's observations above.






Full-sized LZN vs converted JPG



Being "happy with the results", using full-sized _lzn files as a final output, I actually wanted to prove that they are exactly the same (the images, not the metadata) as "converted" images. For my eyes, they do look the same, but checking the number of unique colours, I get slightly different numbers. (So says IrfanView.)


Two samples, one cropped and one not: 475.391 vs 475.354 and 453.453 vs 453.478 colours. Saved with same settings, colour profile etc. So there is some, although probably tiny, difference in the way files are processed. And I didn't even try to make small crops, rotate them and trigger size differences this time. It looks I'll have to rethink this.




Edit: I made this shorter.


Grant, I'm sorry I really did

Grant, I'm sorry I really did miss your post, don't know how it happened.

Some points:

- Lightzone is - as it is now - a VERY intuitive program. So basically, if you don't want "Done" to be your main output-image saving mechanism, you should make another BIG BUTTON to hit to actually save the output image. It's not intuitive to have to go into a menu for your actual output image. I almost never use convert, I just use the LZN-jpg-container, with quality set to 98 and Don't limit. Yes, I probably don't need the quality 98, but... OR, there should be a publish interface similar to other processing suites, where you collect those images you want to get output quality images from and batch process them, which brings me to my second point... (Yes I know there is batch convert, but it's just not very pretty. )

- As a home user I almost never use the Lightzone image browser. It's almost unbelievably slow and clunky. I always use "Edit in..." either from Lightroom or from Irfanview. The only reason to use it is to Lift/apply tools to a bunch of images. A publish module needs to be faster than that, while still having a thumbnail preview at least, so I can conveniently pick my images.


By now this discussion has veered a bit off course. 

- One more on-topic thing: When hitting "Convert" on a cropped image it will immediately offer me the size of the current crop as an output size. So there IS a way to quickly extract this information and give it as an option. Just using that size for preview saving would solve all the problems.

And I still haven't posted to Github... mainly because I don't quite know how to find it.