Can I flatten/resequence a large PNG file?

[Hicksi]

I have a large PNG file 10000 x 14000, which has been created by overlaying individual screen captures as New Layers, and then Merging them down.

Each new block has not been created in sequence (ie, a road east has been tracked, then a road south, then fill as necessary to create the complete area of the PNG.

 

I have noticed that if I DRAG the whole, that it renders in the order that I applied the segment (layer).  I have noticed similar characteristics with other functions, but the DRAG issue is the easiest to explain.
This seems to indicate that the data in the file is in the same sequence as when it was created.  And maybe even still contains pieces of the overlaid segments.

Is there a way to force the complete re-sequence of the bits in the file which would avoid the overheads of rendering (or even create a smaller file)?

[Rick Brewster]

I'm sorry but this makes no sense at all, I can't figure out what you're trying to explain/illustrate. Maybe a video would explain it better.

[Lemonade]

Are you referring to "rendering blocks" while dragging merged layer with Move tool?
Instead of merge down layers order 1, 3, 4, 2 and so on, what you experience is paint.net shows them in order of layer creation (1, 2, 3, 4) but just while dragging with move tool?

Edited November 14 by Lemonade

[Tactilis]

@Hicksi I tried to reproduce what you have described by:
- creating a huge multi-layer image with different coloured rectangles in each layer

- merging the layers down

- zooming in

Then:
1. Used the Pan tool (H) to change the viewed part of the image

2. Used the Move Selected Pixels tool (M) to move the pixels of the entire image.

Pan is always smooth because you are just moving a 'viewport' around on the fixed image.
Move produces blocky rendering as you drag the pixels around. The entire image is being changed. The visible blocks are an artefact of the implementation. The degree of smoothness you get depends on the performance of your disk/CPU/GPU/etc. This is to be expected.


 

8 hours ago, Hicksi said:

I have noticed that if I DRAG the whole, that it renders in the order that I applied the segment (layer).  I have noticed similar characteristics with other functions, but the DRAG issue is the easiest to explain.
This seems to indicate that the data in the file is in the same sequence as when it was created.  And maybe even still contains pieces of the overlaid segments.

Is there a way to force the complete re-sequence of the bits in the file which would avoid the overheads of rendering (or even create a smaller file)?

What is the purpose of your DRAGing?  Do you mean that you are doing a Move Selected Pixels of the entire image? Should you be PANning instead?

Why does it matter to you the order in which the blocks of pixels are rendered? If you stop moving you mouse for a moment then the displayed image 'catches up'.

If the process of moving & rendering pixels is too slow for you then maybe you need a faster disk/CPU/GPU and more RAM.

[Hicksi]

OK.  I may be tilting at windmills with this question as asked.
So I tried generating a 10000x10000 and layering a 2000x2000 multiple times.  Then merged them all down.
Saving this (as png) created a 31,586 KB file.
Closed Paint and re-opened.  When I try dragging, etc, it seems to render the components of each block, somewhat in the order they were created.

Closed Paint and re-opened.  Without change, I saved as jpg.  That created a 3,296 KB file.  Nothing unexpected here.

Closed Paint and opened the jpg file.  Without change, I saved as png again.  That created a 7,277 KB file.  And here is the surprise.  That's 25% of the original.  SO, what has been "compressed" or "lost" in the transition?  The rendering now seems to be related to blocks around my cursor, quite different to the original experience.
 

So, it may be that I asked the wrong question.  There is a significant difference between the png file created by layering and merging (particularly as I ensured that I had layers overlapping), and that created by converting to jpg and back.
I am wondering what that difference and whether there is a method to "resequence" or "discard rubbish" without performing the double conversion.

[Hicksi]

On 11/14/2023 at 8:09 PM, Tactilis said:

@Hicksi
What is the purpose of your DRAGing?  Do you mean that you are doing a Move Selected Pixels of the entire image? Should you be PANning instead?

Why does it matter to you the order in which the blocks of pixels are rendered? If you stop moving you mouse for a moment then the displayed image 'catches up'.

If the process of moving & rendering pixels is too slow for you then maybe you need a faster disk/CPU/GPU and more RAM.

- Dragging wasn't the "purpose", rather it was a task that indicated the issue I was wanting to describe.

- The "rendering" seemed to indicate to me that there was a lot of rubbish in the file, and that it (like MS-Word) adds changes to the end of the file and somehow marks earlier pixels as being removed.  And my testing that I just described indicates that ~75% of this overlaid picture could be nulled out rubbish.
My enquiry was to understand if there was a function to purge that nulled segments (which presumably would resequence the pixels so the rendering seemed logical).

[frio]

By saving the file as a JPG you already destroyed a lot of the small detail, so PNG was able to compress it higher than initially. This is not always the case, and you should just be saving JPG directly if the space the file takes is more important than quality. Both are unlayered formats so both save the same amount of pixels; there is no "rubbish" saved in either format. 

 

Your 10,000x10,000 image has 100,000,000 pixels taking up around 0.4 GB of memory, the image in memory has no relation to the file format; trying to move amounts of data like that is a big demand and blocky rendering (multiple threads working at their own pace on small blocks) is a much better option than sluggish, unresponsive attempts to move the entire huge image in one go.

[Rick Brewster]

There's no "rubbish" in the file. That doesn't make any sense ¯\_(ツ)_/¯

[Tactilis]

5 hours ago, Hicksi said:

I may be tilting at windmills with this question

You are.

 

Quote

1. The "rendering" seemed to indicate to me that there was a lot of rubbish in the file,

2. and that it (like MS-Word) adds changes to the end of the file and somehow marks earlier pixels as being removed.

3. And my testing that I just described indicates that ~75% of this overlaid picture could be nulled out rubbish.

4. My enquiry was to understand if there was a function to purge that nulled segments

You have jumped to a bizarre set of conclusions with no basis in fact:

1. No.
2. No (and that's not how MS-Word files work).

3. No.

4. No, because of 1, 2 and 3

Have you looked at the PNG specification?