should I develop a new gfx-ripper? - Page 3

bLAZER · 07 July 2007, 04:45

As I said however, the image I attached is a screenshot from GfxRip, and thus doesn't use SaveBMP from Allegro...

tomcat666 · 07 July 2007, 06:20

Thats why I also wrote this at the end:

"Also it does seem allegro doesn't use the same algorythm for SaveBmp() and to display a 6bit palette on a 16/32 bit screen Since you get different values for both. Ah well.. Anyway, I think all of this is OK, since Amiga's resolution is 4bit and we can differently upscale to 6/8bit ..."

It still needs to upscale the 6bit values somehow to display on a 8,16 or 32 bit display... and it upscales differently... I don't see a problem here. It is true it isn't upscaled the same as WinUAE does it, but it is upscaled PROPERLY.

bLAZER · 12 July 2007, 03:14

New in version 0.6:

Drag and drop support for ripper state files
Save images
Preferences: Default directory for saving images
Window position is saved in settings file
More accurate colors in palette
Warns if there is a mismatch between uss-files when loading a ripper state

Get it at http://andreas.blazer.nu/DeluxeGfxRipper.zip

zenox98 · 12 July 2007, 11:28

@bLAZER
You're a star.

BippyM · 12 July 2007, 17:43

Stunning keep it up mate ;D

StingRay · 13 July 2007, 00:31

Maybe I am missing something here but about this 4bit-6/8 bit conversion, why don't you just save the original i.e. not converted images? I don't see why you have to convert them? I would f.e. just attach an iff header and save the image then.

Edit: ok, just checked the tool and I think I know why.

thought it would be a generic graphics ripper, not just one that "only" works with UAE save states.

So I suppose the gfx are already internally converted by UAE? If not, then my question about why the conversion is necessary still remains.

bLAZER · 13 July 2007, 00:38

One thing is that most library's for developing only support 8-bit,16-bit etc, and not 4-bit images, for example QT, that I use. And Allegro uses 6-bit I believe.

StingRay · 13 July 2007, 00:47

Hmm, well, can't you just create an image header yourself and save the data then? That's how I would do it at least. If people want to use the pictures with other programs that don't support 4bit, they can convert them themselves. That's how I see it at least. After all, a graphics ripper should rip the original graphics.

bLAZER · 13 July 2007, 03:03

I guess that's possible, but I can't show the pic in 4-bit with QT without some kind of conversion. I guess I could save the "original" image though, to some amiga-format... like iff. But then I'll have to write a iff-writer myself...Don't know how much people care about that accuracy though.

Edit: Also I'm not exactly sure how WinUAE stores the colors, if they are stored as 4-bit in the state-file... haven't looked into it that much.

StingRay · 13 July 2007, 03:27

IFF is a pretty simple format, lots of information can be found on the net. I'd offer my help as well if needed as I think I know that format very well.

About accuracy, well, I definitely won't like a gfx ripper that saves out modified graphics. Would be the same as a module ripper that just converts samples. It is just not the original data and personally I do not like that. Converting the graphics to show them in the GUI is totally ok but the data that is saved should not be modfied at all. At least you might think about a setting that enables the user to choose between original/converted data for saving.

I have no idea about UAE's save state format at all as I never needed/used that feature but I guess Toni could help you there. Also, how about allowing to load arbitrary data files and scanning them for example for iff graphics? Might be a useful feature to have.

Asle · 03 November 2007, 23:20

http://andreas.blazer.nu/DeluxeGfxRipper.zip doesn't seem to work anymore.
someone has it somewhere else ?

CodyJarrett · 04 November 2007, 10:00

I've uploaded it to the Zone.

Calgor · 04 November 2007, 10:41

Quote:

Originally Posted by bLAZER

About the palette, does this mean that every image ever ripped with gfxrip is darker? Oh the horror! And a question, allegro uses 6bit colors and I use 8bit color. So if I want to convert a color 63,63,63 to 8 bit I multiply it with 4: 63*4 = 252 that gives 252,252,252. But shouldn't maximum white in 6bit (63,63,63) be maximum white in 8bit (255,255,255)? So what's the correct algorithm here?

I must be missing something in this thread on how the palette values are stored, but wouldn't you just do 8bit value = (X+1)*2^(bit difference) -1 ?

i.e. (63+1)*4 - 1 = 255

bLAZER · 08 November 2007, 22:44

My server is a bit unstable at the moment so that's why the program wasn't downloadable, server is down some minutes here and there.

Calgor, yeah that seems to work sort of... 0,0,0 in 6-bit will be 3,3,3 in 8 bit though... but I don't know if there are any rules that forbids that...

In other news: I've been modifying the GUI and some other stuff, have some issues still, but I'll hopefully release a new version "soon".

Calgor · 09 November 2007, 07:01

@bLAZER

yes, good point (as also earlier in this thread...). Problem is, if we have in both precisions that 0 is full black, then there are 63 extra points corresponding to 255 extra points. 255 is not exactly divisible by 63, so how do we then get the 8-bit colours to be a superset of the 6-bit colours? That is, assuming that all 255 points are equidistant.

The only way around that I can see for an exact match of colours is if in 8-bit either black is blacker or white is whiter or both - but from Toni's comment I infer that full white is the same in both palettes.

Toni Wilen · 09 November 2007, 08:18

I already explained how to do it

6 bit ABCDEF to 8 bit = ABCDEFEF (repeat lowest bits)

Calgor · 09 November 2007, 10:01

@Toni

But does that mean it will be exactly accurate? (1 becomes 5, 2->10, 3->15, 4->16, 5->21,...)

Not all 6-bit values are equidistant once converted to 8-bit, and 3 and 4 are close together.

Maybe there is no exact answer, or my maths are wrong, or my understanding of palettes is wrong...

thor · 09 November 2007, 10:52

If you do repeat the upper 2 not the lower 2 bits, you'll get a more equidistant result with all colors at distance 4 except three ones at distance 5 (when one of the upper 2 bits of the 6 changes).

So conversion is ABCDEF -> ABCDEFAB

Toni Wilen · 13 November 2007, 13:22

Quote:

Originally Posted by thor

If you do repeat the upper 2 not the lower 2 bits, you'll get a more equidistant result with all colors at distance 4 except three ones at distance 5 (when one of the upper 2 bits of the 6 changes).

So conversion is ABCDEF -> ABCDEFAB

Yeah, I guess this works better in this case but proper fix is not to use 6-bit colors

Calgor · 13 November 2007, 15:31

So does this mean that 24-bit palette is not superset of 18-bit palette? It would appear to be a superset of the OCS 12-bit palette as 255 is exactly divisible by 15. Which of course is good for AGA chipset emulating OCS chipset. Yes, so as Toni says, do not use 6-bit colours

12 July 2007, 03:14	#43
bLAZER Awesome to the max Join Date: Mar 2007 Location: Gothenburg / Sweden Age: 47 Posts: 1,006	New in version 0.6: Drag and drop support for ripper state files Save images Preferences: Default directory for saving images Window position is saved in settings file More accurate colors in palette Warns if there is a mismatch between uss-files when loading a ripper state Get it at http://andreas.blazer.nu/DeluxeGfxRipper.zip

13 July 2007, 00:31	#46
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	Maybe I am missing something here but about this 4bit-6/8 bit conversion, why don't you just save the original i.e. not converted images? I don't see why you have to convert them? I would f.e. just attach an iff header and save the image then. Edit: ok, just checked the tool and I think I know why. thought it would be a generic graphics ripper, not just one that "only" works with UAE save states. So I suppose the gfx are already internally converted by UAE? If not, then my question about why the conversion is necessary still remains. Last edited by StingRay; 13 July 2007 at 00:37.

13 July 2007, 03:27	#50
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	IFF is a pretty simple format, lots of information can be found on the net. I'd offer my help as well if needed as I think I know that format very well. About accuracy, well, I definitely won't like a gfx ripper that saves out modified graphics. Would be the same as a module ripper that just converts samples. It is just not the original data and personally I do not like that. Converting the graphics to show them in the GUI is totally ok but the data that is saved should not be modfied at all. At least you might think about a setting that enables the user to choose between original/converted data for saving. I have no idea about UAE's save state format at all as I never needed/used that feature but I guess Toni could help you there. Also, how about allowing to load arbitrary data files and scanning them for example for iff graphics? Might be a useful feature to have. Last edited by StingRay; 13 July 2007 at 03:40.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Jack The Ripper	Steve	request.Old Rare Games	4	08 August 2015 00:10
The Future Depends on YOU! Help develop new Amiga games!	Cammy	Amiga scene	22	30 September 2009 17:51
suggestions for a ripper?	snyp	Coders. General	0	28 May 2006 15:15
If I could develop an Amiga now, it would have.....	7-Zark-7	Retrogaming General Discussion	2	16 November 2001 18:41

07 July 2007, 04:45	#41
bLAZER Awesome to the max Join Date: Mar 2007 Location: Gothenburg / Sweden Age: 47 Posts: 1,006	As I said however, the image I attached is a screenshot from GfxRip, and thus doesn't use SaveBMP from Allegro...

07 July 2007, 06:20	#42
tomcat666 Retro Freak Join Date: Nov 2001 Location: Slovenia Age: 51 Posts: 1,647	Thats why I also wrote this at the end: "Also it does seem allegro doesn't use the same algorythm for SaveBmp() and to display a 6bit palette on a 16/32 bit screen Since you get different values for both. Ah well.. Anyway, I think all of this is OK, since Amiga's resolution is 4bit and we can differently upscale to 6/8bit ..." It still needs to upscale the 6bit values somehow to display on a 8,16 or 32 bit display... and it upscales differently... I don't see a problem here. It is true it isn't upscaled the same as WinUAE does it, but it is upscaled PROPERLY.

12 July 2007, 11:28	#44
zenox98 Joy Division Join Date: Nov 2006 Location: East Yorkshire Age: 60 Posts: 239	@bLAZER You're a star.

12 July 2007, 17:43	#45
BippyM Global Moderator Join Date: Nov 2001 Location: Derby, UK Age: 48 Posts: 9,355	Stunning keep it up mate ;D

13 July 2007, 00:38	#47
bLAZER Awesome to the max Join Date: Mar 2007 Location: Gothenburg / Sweden Age: 47 Posts: 1,006	One thing is that most library's for developing only support 8-bit,16-bit etc, and not 4-bit images, for example QT, that I use. And Allegro uses 6-bit I believe.

13 July 2007, 00:47	#48
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	Hmm, well, can't you just create an image header yourself and save the data then? That's how I would do it at least. If people want to use the pictures with other programs that don't support 4bit, they can convert them themselves. That's how I see it at least. After all, a graphics ripper should rip the original graphics.

13 July 2007, 03:03	#49
bLAZER Awesome to the max Join Date: Mar 2007 Location: Gothenburg / Sweden Age: 47 Posts: 1,006	I guess that's possible, but I can't show the pic in 4-bit with QT without some kind of conversion. I guess I could save the "original" image though, to some amiga-format... like iff. But then I'll have to write a iff-writer myself...Don't know how much people care about that accuracy though. Edit: Also I'm not exactly sure how WinUAE stores the colors, if they are stored as 4-bit in the state-file... haven't looked into it that much.

03 November 2007, 23:20	#51
Asle Registered User Join Date: May 2006 Location: Paris/France Age: 52 Posts: 526	http://andreas.blazer.nu/DeluxeGfxRipper.zip doesn't seem to work anymore. someone has it somewhere else ?

04 November 2007, 10:00	#52
CodyJarrett Global Moderator Join Date: Mar 2001 Location: UK Age: 46 Posts: 6,160	I've uploaded it to the Zone.

08 November 2007, 22:44	#54
bLAZER Awesome to the max Join Date: Mar 2007 Location: Gothenburg / Sweden Age: 47 Posts: 1,006	My server is a bit unstable at the moment so that's why the program wasn't downloadable, server is down some minutes here and there. Calgor, yeah that seems to work sort of... 0,0,0 in 6-bit will be 3,3,3 in 8 bit though... but I don't know if there are any rules that forbids that... In other news: I've been modifying the GUI and some other stuff, have some issues still, but I'll hopefully release a new version "soon".

09 November 2007, 07:01	#55
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	@bLAZER yes, good point (as also earlier in this thread...). Problem is, if we have in both precisions that 0 is full black, then there are 63 extra points corresponding to 255 extra points. 255 is not exactly divisible by 63, so how do we then get the 8-bit colours to be a superset of the 6-bit colours? That is, assuming that all 255 points are equidistant. The only way around that I can see for an exact match of colours is if in 8-bit either black is blacker or white is whiter or both - but from Toni's comment I infer that full white is the same in both palettes.

09 November 2007, 08:18	#56
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	I already explained how to do it 6 bit ABCDEF to 8 bit = ABCDEFEF (repeat lowest bits)

09 November 2007, 10:01	#57
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	@Toni But does that mean it will be exactly accurate? (1 becomes 5, 2->10, 3->15, 4->16, 5->21,...) Not all 6-bit values are equidistant once converted to 8-bit, and 3 and 4 are close together. Maybe there is no exact answer, or my maths are wrong, or my understanding of palettes is wrong...

13 November 2007, 15:31	#60
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	So does this mean that 24-bit palette is not superset of 18-bit palette? It would appear to be a superset of the OCS 12-bit palette as 255 is exactly divisible by 15. Which of course is good for AGA chipset emulating OCS chipset. Yes, so as Toni says, do not use 6-bit colours

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)