Requested Mapping selected portion of the image in the HEX viewer Window or vise-versa

[vikramtheone]

Hi Irfanviewer,
I recently started using Irfanviewer and I love it.

I want to suggest a feature enhancement request to you, I don't know for sure if this has already been implemented or already asked by others or not.

Here it goes -

The viewer supports HEXView of an image, I work on the HEX view of an image a lot, well from my experience I feel that it would awesome if when a particular portion of the image is selected in the image viewer the corresponding pixel values get highlighted in the HEXView as well. With this it would be a great help to people like me who would like to know exactly what portion of the image we are viewing currently.

Regards
Vikram

[Sam_Zen]

Seems like a good idea

[MItaly]

This could be done with DIBs, but not with any other format (or, at least, it would be really difficult).

[dorami]

But you understand that the hexview shows a hex dump of the file content.
In most cases the file content is packed.
So it is impossible to get a match between the selection and hexdump.
Even for the remaining files you need a mapper for each file format.
How many people do you think need this?

[MItaly]

Yes, it's exactly my point; since IV plainly loads the DIBs in memory there's a 1:1 correspondence between the file and the loaded DIB (as long as it's not modified), but when we start to talk about compressed formats (even RLE compressed bitmaps) this assumption isn't true anymore, so some (extremely complicated if not impossible) mapping has to be done. A viable alternative would be to add to the hex viewer an option to view the loaded image as it is in memory, i.e. the DIB that IV is internally using; this wouldn't be much complicated, still I don't see how could this be useful, except for debugging purposes (but when I'm debugging IrfanPaint or the JPEG2000 plugin I can already see easily all the memory with the debugger, so it wouldn't be useful even for me).

[dorami]

MItaly, I replied to vikramtheone. I know that you are understanding the technical details.

[WellOiledPC]

MItaly, I replied to vikramtheone. I know that you are understanding the technical details.

Well, MItaly began his post with "Yes, it's exactly my point:", continues to explain in great detail the difficulty of presenting Hex views for compressed files and finally, has posted what could be possible ways, with the comment that it may not be too useful. Thats a very comprehensive answer!

[Sam_Zen]

Hm, I indeed forgot about the representation of a compressed file..

[vikramtheone]

I'm not so good at the software side so can't make out completely, but I can understand some points from your discussion.

As far as how many people need it, well in my university I have many courses dealing with images and in almost all those projects there will be a time when many students end up using a HEXEditor. I use Notepad++ HEXEditor and when I have to find out which pixels I'm working on currently, I simply change a large set of pixel values to (BLACK OR WHITE) and look at the corresponding changes in the image.

[WellOiledPC]

Well, I'm sure you're far better at programming than me, as you actually study courses dealing with images...! The difficulty, as MItaly has clearly stated, comes from the fact that JPG (and many other image format) files are highly compressed. Naturally then, the HEX views of compressed files would be completely different from that of the same, uncompressed file.

This is a very friendly Forum and perhaps if you explain a bit about;

1. just when you use a HEX editor on images
2. what image format(s) you work with
3. ultimately, what you do to the images, working with them in HEX mode

the members here who are into programming can help...

[Sam_Zen]

Do mind too, that different formats use different algoritms for compression.
The order of the description of the pixel values of a GIF file differs from a JPG.

[MItaly]

Not only that: in a compressed file the pixels may be rearranged in a completely different manner; for example, IV works with RGB images, but internally JPEG uses YCbCr images to compress better. Even more difficult: in JPEG the Y component and the Cb/Cr ones are stored with different precision: usually the Y is stored at full resolution, while the Cb and Cr are stored in smaller images. So, there's no (feasible) way to fulfill this request other than providing a hex view for the loaded, in-memory DIB.