JpegCrop Run on ReactOS?

[Haos]

Yes, database is no longer supported.

Does XnView or JpegCrop run on Reactos?

Why dont you try it and tell us?

Are you using ver 4.0 or just saw ver 4.1?

I`m afraid i`m still with 3.98. Will look into the new version soon.

Here is a link to 4.1...

Posting the link only would suffice. Thx.

And please do not multipost. Just edit your former post.

[oiaohm]

XnView is a commercial tool. Yes all features out box even in the free trial version/home use.

Most versions IrfanView can do it as long as it has its plugin kit.

http://www.irfanview.com/ Sorry last link broke pick plugin from side and download that file as will. Install irfranview first then its exe of plugins.

There are more tools around that don't appear on the lists of losses jpeg alteration that can do it as well.

I have not tried XnView under reactos yet. Simple reason it runs under Linux and Windows. No need for me and I only have the linux binary at moment.

[eXile]

Hi,

eXile losses jpeg processing is kinda different.

Heck, I cannot understand what you want to say.

Most programs that do work like JpegCrop are called viewers. Not editors because they don't alter the data as such.

From a mathematical point of view, you are wrong. As the original entropy of any image (or field with discrete values) is only lowered by a set of operations on it, the data is altered as such. This does not mean in any, that the discrete value of any element of the field needs to be changed, but that does not mean, that the data is not altered, as the elements of the field could be reduced by the respectivly applied operations.

They are not altering the image data.

It is still not clear what your statement expresses. But as i described before, this is by no means "lossless" - as any operation lowers the entropy of the recording of reality (here: the image). So why is your statement not clear? Simply because you did not exactly define what "image data" means. By a matter of information, the "image data" is always lowered when cropping images.

Say sorry eXile. Since you did not understand what the person was talking about.

I would say it the other way around, the person did not understand in a mathematical exact way what I answered to him. General statements like "It is lossless" were not determinable from it's local context in the persons last post. That is why I said that the named person should think again about the mathematics behind it.
So instead of saying sorry I better give you the advice to try to analyse problems as often as possible in a mathematical way, otherwise strange conclusion could come up.

You don't use gimp or photoshop even for minor adjustments on jpegs due to the dataloss from both way conversion.

That is because you do not use gimp or photoshop and jpegs due to the reduced information at all, except for final storage.

Cheers,
eXile.

[counting_pine]

When you crop a JPEG with JPEGCrop, you obviously lose image data, but the image data that remains is exactly the same as it was before you cropped it. It only loses data in the same way that you lose data when cropping a PNG.
This isn't true if you load and save an image in a conventional image editor. (Unless you're using an explicit lossless crop function, such as in IrfanView).

I have to disagree that the operations JPEGCrop performs aren't useful on their own.
It's entirely possible that you might just want to rotate an image 90 degrees, or crop it, or convert it to greyscale.
Maybe it would be desirable to perform more operations like fine rotation or colour correction, but these come at a price. To fully preserve the image data, you need to save as a PNG, but you suffer a considerable file size increase. To reduce the file size, you have to save as JPEG. But then you have to try and find a compromise with the quality.
The most efficient setting (most amount of useful data per bit) would be about the same quality that it was previously encoded in, but any setting will lose data.
In order to preserve the original efficiency of the image, you have to restrict yourself to the simple operations provided in JPEGCrop. In many cases, those restrictions are worthwhile, and in some cases they don't even pose much of a hindrance at all.

[oiaohm]

eXile you really don't understand it. Lossless Jpeg are a special set of operations supported by the jpeg formats header.

Lossless jpeg allows you to turn and flip the data on 90 deg values is 0 90 180 270.

Note this is cheating really. Its just rendering the data at a different angle or order at output the base data used has not changed at all.

Losses cropping in Jpegs can be exactly that. Still the data is not changed instead its told to display a section instead of the complete thing. The true losses jpeg does not cut the edges off just does not render the edges you don't want so you can always undo it. So 100 percent lossless.

Even zooming the image is the same. The same ammout of data is in the image when you start and when you finish. You can alway reverse the operations back to what they were.

At no time are you altering the image data. You hare altering a little bit of header that says how it will be displayed. Its a different type of operation. Completely losses. No recoding just a little bit of header tweeking effecting display.

At no time do any of these operations effect entropy. At worst section is hidden.

The maths perfectly fine.

Lossless jpeg operations are only good for minor alterations. Yes and really really limited because anything out side them will lose data. Yes its really bad if a person uses lossless to produce thumb nails. Since the jpeg file will not reduce in size.

counting_pine you were close. As you can see a lot of people foot in month how losses jpeg works.

eXile just in future please make sure you have a understanding about how something works before saying its wrong. Its better to ask how does losses jpeg work then say to a person its imposable. Just say sorry for the wrong line. Note it would be a rare day that I would miss something like a entropy alteration. That is only simple thing.

As well in future do not call me wrong when its a understanding problem. You were not understanding what was going on. Just ask me to explain it more. Lot of times I will short hand stuff. The Information is there if you understand my short hand.

[eXile]

Hi,

I did understood the math behind it perfectly. By the proposed approach it possible e.g. to crop an image (here: discrete values of a field) without altering the grade of information of any other pixel not cropped (here: any other discrete value of the field).

Still, you did not define what "image data" is, which is the main problem of this discussion. I defined "image data" as the whole information recorded in the original instance of the image as a projection of all data recordable in reality by an image at itself. This is obviously a very natural way of defining the term "image data".

And now only according to this definition (which is the basis of discussion): Any cropping of more than one value would yield to an loss of information (reduction of entropy in this special case), thus to a loss of "image data", thus it is not lossless. The entropy is lowered, because you cannot uncrop the cropped area in a way that is restores the original image, because the data in the cropped area is lost.

Or once again strikingly: You got an image of a blue and a red box, crop the image so that the red box is not shown anymore. Next step. You uncrop the previously cropped region, but the red box does not pop up again (logically), because the data representing the red box is lost.

At no time I said, that this is a problem of the algorithm. I was only unhappy with the term "It is lossless", as any cropping is not lossless.

This is really obvious, but as the examination of entropy showed, it could also be proved mathematically.

Cheers,
eXile.

[betaluva]

xnview 1.68 runs on reactos but but it crashes when you try open any images? [ external image ]

[oiaohm]

A true Jpeg losses crop is not a crop by normal define that is the problem. eXile.

I am using image data in the term of the jpeg format itself.

Ie [header] This is at the start of file. Explaining stuff like image size and how to should be displayed.
[image data] All the information that makes up a picture. These are two different sections of the file.

I love when people try pointing to the display bits of lossless. The boxes are created by header information. The important bit of lossless operations is that you can change them without getting less data to play with.

Of course there are changes of bits. The lossless bit is that you could change you mind on any lossless jpeg operation and get back to where you started.

You are not understanding Jpeg losses crop if you did crop the redbox out then undo the crop it would be back as if nothing change even if it was years latter. Only thing you loss when changing the crop is the displayed area information. You have to be careful with losses jpeg operations because it does not destroy.

Closest thing I can think of is image cropping in word or writer. These cropping don't change the image but put display limits on it. Jpeg losses crop is the same.

It is completely incorrect eXile that all forms of cropping cause loss. Display cropping the data is always there.

Other good example is a picture frame you put a bit of paper with oval hole over a picture in it. This is a display crop. The image is now not oval shape and the data that the oval hide is still there if you remove the oval. That is what jpeg losses crop is doing in a more limited form.

Now the other form would be a image alteration crop where you would cut the image into a oval. Now that is not undo able. Yes there are two forms of cropping.

So you are basically taken the word crop completely out of context.

[Z98]

You two, calm down. You're both basically explaining two different things while assuming you're talking about the same thing.

[eXile]

Yeah thats rights, I will stop posting answers in this thread as the thing I am talking about is obviously taken for something else. As I mentioned before, our definition of "image data" is different, so our discussion is useless