Jump to content
Jagware
SebRmv

Jaguar Image Converter

Recommended Posts

Zerosquare    10

Updated software -> updated bug report :P

converter_0.1.6.png

Well, it's better that it was. :)

But there are still weird things on the converted picture : yellowed areas (look around the eye of the left-side parrot, for example), and a visible "separation line" on the background.

Share this post


Link to post
Share on other sites
SebRmv    2

not really a bug :whistling:

but a new fix is coming soon...

Share this post


Link to post
Share on other sites
SebRmv    2

and here comes 0.1.7 version!

 

hope this time is the good one ;)

Share this post


Link to post
Share on other sites
Zerosquare    10

I don't know any converter which does this.

 

If it's only for viewing, or if you have just a few images to convert, you can use JagViewer and take screenshots. (Beware though, it seems to be a bit buggy ; the colors are slightly wrong) : JagViewer.zip

 

If you have a lot of pictures to convert... I guess I could write a converter (I have most of the needed code already written for other projects).

But it cannot be fully automatic, as there isn't any way to know the location and the size of the images in the ROM.

 

In both cases, it won't work if the pictures are compressed in any way.

Share this post


Link to post
Share on other sites
Doctor Clu    0
I don't know any converter which does this.

 

If it's only for viewing, or if you have just a few images to convert, you can use JagViewer and take screenshots. (Beware though, it seems to be a bit buggy ; the colors are slightly wrong) : JagViewer.zip

 

If you have a lot of pictures to convert... I guess I could write a converter (I have most of the needed code already written for other projects).

But it cannot be fully automatic, as there isn't any way to know the location and the size of the images in the ROM.

 

In both cases, it won't work if the pictures are compressed in any way.

 

Well by some great advice from many and luck, we have a decompiled (about 91%) Bubsy with almost all of the material in it uncompressed.

 

At first the viewer above would not look at what we came up, but I renamed it ".bin" and and it was able to see it.

 

The image viewer was quite versatile, but didn't quite have the colors right.

 

Here we have Pal 8 bit

post-189-1250210889_thumb.jpg

Here is the .cry version

post-189-1250210930_thumb.jpg

And here is the RGB version

post-189-1250210979_thumb.jpg

 

Now that pink or red sky is supposed to be blue. Other than that, this was amazingly better that trying to MANUALLY figure out the image in raw format only to get grey images. Just amazing.

 

If you could make one better, please make it so!!

 

And here is the original file I was reading.

ALICE.zip

Share this post


Link to post
Share on other sites
SebRmv    2

Hi, got your mail but prefer to answer directly here...

 

As for me, I can also probably extend my Jag Image Converter to do the reverse operation...

I'll probably get some time during my holydays to have a look at this... we'll see.

 

Cheers

Share this post


Link to post
Share on other sites
Doctor Clu    0
Hi, got your mail but prefer to answer directly here...

 

As for me, I can also probably extend my Jag Image Converter to do the reverse operation...

I'll probably get some time during my holydays to have a look at this... we'll see.

 

Cheers

 

Hey thanks that's awesome. Let me know what you find out.

 

Share this post


Link to post
Share on other sites
Zerosquare    10

OK, after looking at it, it's definitely a 400x400 8-bit palettized image, not CRY or RGB16. However the palette is not in the .PIC file. Have you found any other files that could be it ? (i'm guessing it would be named something like "Alice.pal" and be 512 bytes long, or so).

Share this post


Link to post
Share on other sites
Doctor Clu    0
OK, after looking at it, it's definitely a 400x400 8-bit palettized image, not CRY or RGB16. However the palette is not in the .PIC file. Have you found any other files that could be it ? (i'm guessing it would be named something like "Alice.pal" and be 512 bytes long, or so).

 

Ahhh there were files that ended with .RGB. Were these the files to compliment the Alice.Pic file?

 

(Attached.)

 

PS: Why such a strict upload limit?

BSET5.zip

Share this post


Link to post
Share on other sites
Zerosquare    10

I wrote a quick program to convert the pictures to .BMP files. The C source file is included.

8bit_to_bmp.zip

 

So far, it seems to work OK. Here's what I get from the Alice.pic file :

Alice.gif

 

The program must be run from a command line, like this :

8bit_to_bmp <image file> <palette file> <output file> <image width>

 

You have to guess which palette file is the right one (just test them all), and the width of the image.

Only RGB palette files are supported at the moment.

 

Example for converting Alice.pic :

8bit_to_bmp alice.pic bset5.rgb alice.bmp 400

Share this post


Link to post
Share on other sites
Doctor Clu    0

I cannot tell you how cool this is! :) Thank you!

 

So why does this need a pallette file? Not sure what is accomplished by having an image file at one location, and a seperate file for denoting what color goes where. I mean why did they do it this way?

 

(posting this on here and FreeJag)

Share this post


Link to post
Share on other sites
SebRmv    2

Ok, I'll investigate that, maybe at the AC next week-end ;)

 

Share this post


Link to post
Share on other sites
Ok, I'll investigate that, maybe at the AC next week-end ;)

 

Further information...

 

It's processing the input file correctly - because outputting 15 bit CRY makes a valid file. However it is definatly screwing up the regular 16 bit CRY output - also had it with several other files today.

 

Tried importing them as JPG, GIF, etc - same result in the output. Exported as 15bit - worked ok (but obviously useless for lighting efects)

 

Also, neither your or zerosquare's convertors handle RGB 0,0,0 (black) correctly (for transparecny) - yours outputs $0001, and Zero's output's $something01 (can't remember) - a search and replace with $0000 fixes this but it's a bit of a pain.

 

Further note - *both* your convertors *always* get the first word in the file wrong (pixel 0,0).

 

eg, give it a pure black bitmap, and the entire file will contain a single repeating word, with the first word +1 intensity.

 

Hope this helps.

Share this post


Link to post
Share on other sites
Zerosquare    10
Also, neither your or zerosquare's convertors handle RGB 0,0,0 (black) correctly (for transparecny) - yours outputs $0001, and Zero's output's $something01 (can't remember) - a search and replace with $0000 fixes this but it's a bit of a pain.
I know about that bug, and it's even mentioned in the mail I sent you :P

 

Basically it's because my converter uses dithering (Floyd-Steinberg, to be exact) to avoid color banding artifacts, so perfect accuracy is not guaranteed. I added a special case to fix the transparency issue in my (unreleased) RGB16 converter, but I didn't backport it to the CRY one. I'll do it as soon as I can ;)

 

(I thought that SebRmv's converter handled it and worked fine, that's why I didn't release mine).

 

Further note - *both* your convertors *always* get the first word in the file wrong (pixel 0,0).

 

eg, give it a pure black bitmap, and the entire file will contain a single repeating word, with the first word +1 intensity.

Strange. This one is an unknown bug. I'll look into it.

 

Hope this helps.
It sure does :)

Share this post


Link to post
Share on other sites
Zerosquare    10

Here's a fixed version which should handle transparency correctly :

bmp_cry.zip

Usage is : bmp_cry input_file.bmp output_file.cry

 

Only uncompressed 24-bit BMP files are supported.

Lines in the output file directly follow each other (in other words, they're not padded to an integer number of phrases).

 

And here's a version without the dithering :

bmp_cry_nodither.zip

Share this post


Link to post
Share on other sites
SebRmv    2

is there any CRY viewers on computers? or should I test on a real Jaguar?

 

just to be sure I have understood correctly, the command that produces a wrong result is:

 

./converter.opt -cry --16-bits space.bmp isn't it?

 

but

 

./converter.opt -cry --15-bits space.bmp works fine?

 

 

 

Note: I would be less surprised if it was the contrary...

 

Share this post


Link to post
Share on other sites
SebRmv    2
Further note - *both* your convertors *always* get the first word in the file wrong (pixel 0,0).

 

eg, give it a pure black bitmap, and the entire file will contain a single repeating word, with the first word +1 intensity.

 

Hope this helps.

 

When you say "always", does it really mean always or is it only for CRY 16 bits?

 

 

Share this post


Link to post
Share on other sites
SebRmv    2
As said above, the problems are only in CRY16 mode - other modes produce valid files. :)

 

so it is really CRY16 mode? I would have said that it is CRY15 which is buggy (clearly, there is a mistake in it since pixel value is always ORed with 0x1 in this case)

 

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×