Menu
▾
▴
#28 Preserve original palette, resolution and Pixel Aspect Ratio
None
accepted
5
2021-01-17
2018-03-14
No
Nowadays, when converting an image to png, recoil2png optimizes the palette and eliminates the unused colors.
But preserving the original palette as-is is important, specially when the image needs to be edited. IMHO, this should be the default behavior, and an option like --optpalette should be offered for the cases when the optimization is desirable.
The same deal for the image resolution. Ideally, the original resolution should be output. And a --doublepixels option could be offered to either vertically or horizontally double the resolution when necessary.
Last, but not least, it would be nice if the Pixel Aspect Ratio metadata would be set in the PNG file.
This is also the behaviour I would excpect from RECOIL_ToPalette(). An easy solution might be to keep the palette around to use, then possible, instead of calling RECOIL_CalculatePalette() (and RECOIL_SortPalette() obviously).
I would also lika a possibility to disable image scaling that is done only to (very approximately) match the intended pixel aspect ratio. But I guess the scaling sometimes is done because the original hardware was able to render sprites in higher resolution on top of the image (or something similar). Even if a certain format doesn't make use of that, it's less clear if the image should be considered scaled or not.
As for a more fine grained pixel aspect ratio, wouldn't it be possible to just look it up from
RECOILResolution? I know it's not possible to get an exact number without knowing if the image is intended for PAL or NTSC (and probably some other factors), but a reasonable mean value is better than nothing.That's one case, e.g. for G2F and MCH formats with 80x240 graphics overlayed by 160x240 sprites.
Another case is that some platforms allow for mixing graphics modes, with Atari 8-bit having dozens of hardware modes that can be freely mixed on a line-by-line basis. To get a single image out of that, you need to scale up the low-res modes.
This is inconsistent with Atari ST, where the 320x200 images are rendered as 320x200 even though they have the same physical size as the 640x200 home. However, the hardware makes it harder, if not impossible, to mix these two modes.
Yes, the exact aspect ratio should stem from RECOILResolution. This is already rich information, but probably should be extended for the various Amiga IFF modes.
Yes, PAL vs NTSC makes a huge difference. However, I cannot recall a single file format that stores this information.
So, it must be user-selected in the viewer.
Various RECOILResolutions should be either:
Some computers have multiple display connectors, e.g. PAL/NTSC and VGA in Atari Falcon. Again, no information in the file.
ILBM has fields in the header for defining fine grained pixel aspect ratio (just as the pHYs chunk of PNG), even if it's often misused. I detect misuse by calculating the claimed screen aspect ratio, if it adds up to 4:3 the information is most likely correct. So (at least in some cases) it doesn't need to be mapped to any particular hardware resolution to get the correct pixel aspect ratio.
It would be nice to be able to query RECOIL about the more exact pixel aspect ratio with an argument telling if PAL, NTSC or a compromise is preferred for the cases where it's selectable. As an alternative to not scaling up the image to begin with there could be some hint about whether it could be scaled down (which would always be set for Atari ST med res but just maybe for some Atari 8-bit resolutions). I noticed that support for the PNG pHYs chunk is far from universal, so for recoil2png it's probably most useful to always keep the current approximate scaling and write the pHYs chunk in relation to that.
Regarding ILBM, I got extensive information about the various modes plus full test suite from Cholok. He told me that the CAMG chunk should take precedence over the fine aspect ratio in BMHD and indeed there were sample files to support that. RECOIL uses BMHD information when CAMG is absent or specifies an unknown mode.
ILBM files (and many other formats) are not necessarily fullscreen, so you shouldn't expect the 4:3 ratio.
I like the idea of keeping the doubled pixels as they are now and adding fine aspect ratio information. By the way, I'd like to have the physical sizes and not only the aspect ratio. Might be useful for an Augmented Reality port of RECOIL someday. :) If there was no dedicated display, have some "average TV" from the era the machine was most popular in. I'll certainly need help in creating such a database.
I understand the need for extracting the original pixels, but this is of lower priority. Also, this has problems that I listed in my previous message here.
What Windows software can I use to test the pHYs chunk?
I would only like to ask to have an option to output the file without double pixels, while saving the correct Pixel Aspect Ratio for this mode. (Doubled pixels have a different PAR)
BTW, on Japanese image formats, the PAR info tend to be a combination of a metadata field and the machine/video-mode.
Related
Tickets: #28
I don't know enough about different Amiga graphic hardware (I'm only really familiar with the original Amiga 500), but I assumed CAMG could be interpreted slightly differently depending on if you have AGA or not. Since CAMG is the only way to activate HAM (?) I also assumed it could be used by encoders outside the Amiga world. (I'm working on an ILBM encoder with HAM support myself and I would be really surprised if I'm the first one.)
Regarding the aspect ratio, I didn't mean the aspect ratio of the image but of the screen. The file contains information about the screen size (in pixels) as well as the pixel aspect ratio (and image size in pixels of course).
For average size TV from the era I would say 14" was the most common from early 80's to mid 90's (at least in Sweden where I live). I think monitors (which was much less common) usually was 13". TV sizes of 15" wasn't too uncommon, but bigger sizes were quite expensive and rarely used for home computers. It can be noted that the Atari ST required a special monochrome monitor to display high resolution, so I guess it can be assumed that those images are slightly smaller (unless the monochrome monitor was bigger than the color one, I have to look that up).
(As for Windows software supporting the pHYs chunk I have no idea since I don't use Windows.)
CAMG is simply a dump of the Amiga display chip register.
AGA assigned meaning to more bits of it.
Proper ILBMs should have HAM activated in the CAMG chunk.
Some files fail to do that and RECOIL additionally detects HAM if bit depth equals 6 with just 16 palette entries.
I forgot ILBM has a field for screen resolution. RECOIL doesn't use it. Can it be trusted? Also, some modes required video card expansions and custom monitors. Not sure if all were 4:3.
In the '80s many families in Poland couldn't afford a dedicated screen for their home computer which itself costed a fortune. So my first display for my Atari 800 XL was our color TV, it was like 22 inch or so: https://pl.wikipedia.org/wiki/Helios_(telewizor)
Yes, Atari ST's 640x400 required a special monitor.
SD Snatcher, can you give more details on the PAR on Japanese computers? I think these are the most distorted with integer PARs RECOIL currently applies. Did the Japanese computers have dedicated monitors?
Regarding dedicated monitors, the situation with Japanese computers is very similar to the western computers:
As for the pixel aspect ratio decoding, I attached here a bash script I made that is able to extract the metadata from the many Japanese image formats, including the aspect ratio. It should be easy for you to convert the PAR code for RECOIL. Feel free to ask any questions if you need.
I added initial support for PAR. Pixels are still doubled because the support for PAR in PNG is poor, as I checked with http://frs.badcoffee.info/PAR_AcidTest/ :
So it's doubled pixels + precise PAR in metadata. It's already implemented for:
Platforms:
TODO:
PAL/NTSC selection. Should affect both PAR and colors.
Add information for the remaining platforms (help needed!)
Display with PAR in Windows 10 app, Android app, recoilwin, HTML 5.
Windows 10 and Android should be easy, as the image is scaled to the whole window.
RECOILWin and HTML 5 on the other hand do not scale by default. Not sure how to handle that.
Last edit: Piotr Fusik 2021-01-08
Thanks SD Snatcher for the script! I will use that information.
Progress made: